From mailman-admin@ietf.org Thu Apr 1 18:35:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09463 for ; Thu, 1 Apr 2004 18:35:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BiX-0002e3-00 for idr-archive@ietf.org; Thu, 01 Apr 2004 18:35:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BhZ-0002X5-00 for idr-archive@ietf.org; Thu, 01 Apr 2004 18:34:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bgi-0002RM-00 for idr-archive@ietf.org; Thu, 01 Apr 2004 18:33:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99UT-0006xV-JT for idr-archive@ietf.org; Thu, 01 Apr 2004 16:12:45 -0500 Date: Thu, 01 Apr 2004 11:20:33 -0500 Message-ID: <20040401162033.11029.9132.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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, idr-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for idr-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org omkeeh https://www1.ietf.org/mailman/options/idr/idr-archive%40ietf.org From exim@www1.ietf.org Thu Apr 1 23:59:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08993 for ; Thu, 1 Apr 2004 23:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dyy-0000io-Gv for idr-archive@odin.ietf.org; Thu, 01 Apr 2004 21:00:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3220W1A002763 for idr-archive@odin.ietf.org; Thu, 1 Apr 2004 21:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BX6-0005bf-Ub for idr-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:23:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08584 for ; Thu, 1 Apr 2004 18:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BX4-0001Lh-00 for idr-web-archive@ietf.org; Thu, 01 Apr 2004 18:23:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BWA-0001FY-00 for idr-web-archive@ietf.org; Thu, 01 Apr 2004 18:22:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9BVf-000198-00 for idr-web-archive@ietf.org; Thu, 01 Apr 2004 18:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99EL-0001Xc-GS for idr-web-archive@ietf.org; Thu, 01 Apr 2004 15:56:05 -0500 Date: Thu, 01 Apr 2004 11:17:54 -0500 Message-ID: <20040401161754.11029.77147.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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, NO_REAL_NAME autolearn=no version=2.60 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 Fri Apr 2 14:51:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24893 for ; Fri, 2 Apr 2004 14:51:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UhD-0004uK-00 for idr-archive@ietf.org; Fri, 02 Apr 2004 14:51:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UgJ-0004ik-00 for idr-archive@ietf.org; Fri, 02 Apr 2004 14:50:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ufm-0004Z9-00; Fri, 02 Apr 2004 14:49:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S0V-0005kp-1i; Fri, 02 Apr 2004 11:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9PgA-00022V-5w for idr@optimus.ietf.org; Fri, 02 Apr 2004 09:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10540 for ; Fri, 2 Apr 2004 09:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Pg8-0006l1-00 for idr@ietf.org; Fri, 02 Apr 2004 09:29:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Pf9-0006fB-00 for idr@ietf.org; Fri, 02 Apr 2004 09:28:52 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B9PeB-0006Tu-00; Fri, 02 Apr 2004 09:27:51 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i32ERKl96082; Fri, 2 Apr 2004 06:27:20 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i32EREJ30570; Fri, 2 Apr 2004 06:27:14 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200404021427.i32EREJ30570@merlot.juniper.net> To: Alex Zinin , Bill Fenner cc: idr@ietf.org, iesg-secretary@ietf.org, skh@nexthop.com, yakov@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9681.1080916034.1@juniper.net> From: Yakov Rekhter Subject: [Idr] BGP Extended Communities to Proposed Standard 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, 02 Apr 2004 06:27:14 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex and Bill, The IDR WG would like to ask the IESG to advance BGP Extended Communities to a Proposed Standard. The spec is draft-ietf-idr-bgp-ext-communities-07.txt. The implementation report is draft-rekhter-ext-communities-survey-02.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 2 16:44:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03319 for ; Fri, 2 Apr 2004 16:44:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WSW-0001lU-5H for idr-archive@odin.ietf.org; Fri, 02 Apr 2004 16:44:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LiG22006784 for idr-archive@odin.ietf.org; Fri, 2 Apr 2004 16:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UhI-00015m-Hw for idr-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 14:51:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24919 for ; Fri, 2 Apr 2004 14:51:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UhF-0004ud-00 for idr-web-archive@ietf.org; Fri, 02 Apr 2004 14:51:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UgL-0004j0-00 for idr-web-archive@ietf.org; Fri, 02 Apr 2004 14:50:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ufm-0004Z9-00; Fri, 02 Apr 2004 14:49:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S0V-0005kp-1i; Fri, 02 Apr 2004 11:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9PgA-00022V-5w for idr@optimus.ietf.org; Fri, 02 Apr 2004 09:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10540 for ; Fri, 2 Apr 2004 09:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Pg8-0006l1-00 for idr@ietf.org; Fri, 02 Apr 2004 09:29:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Pf9-0006fB-00 for idr@ietf.org; Fri, 02 Apr 2004 09:28:52 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B9PeB-0006Tu-00; Fri, 02 Apr 2004 09:27:51 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i32ERKl96082; Fri, 2 Apr 2004 06:27:20 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i32EREJ30570; Fri, 2 Apr 2004 06:27:14 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200404021427.i32EREJ30570@merlot.juniper.net> To: Alex Zinin , Bill Fenner cc: idr@ietf.org, iesg-secretary@ietf.org, skh@nexthop.com, yakov@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9681.1080916034.1@juniper.net> From: Yakov Rekhter Subject: [Idr] BGP Extended Communities to Proposed Standard 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, 02 Apr 2004 06:27:14 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex and Bill, The IDR WG would like to ask the IESG to advance BGP Extended Communities to a Proposed Standard. The spec is draft-ietf-idr-bgp-ext-communities-07.txt. The implementation report is draft-rekhter-ext-communities-survey-02.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 2 22:07:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20425 for ; Fri, 2 Apr 2004 22:07:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bVD-0007K4-00 for idr-archive@ietf.org; Fri, 02 Apr 2004 22:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bUF-0007CE-00 for idr-archive@ietf.org; Fri, 02 Apr 2004 22:06:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9bTM-00075H-00; Fri, 02 Apr 2004 22:05:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bSv-0002Wi-8P; Fri, 02 Apr 2004 22:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bSL-0002SU-Ny for idr@optimus.ietf.org; Fri, 02 Apr 2004 22:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20382 for ; Fri, 2 Apr 2004 22:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bSI-0006xZ-00 for idr@ietf.org; Fri, 02 Apr 2004 22:04:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bRU-0006r6-00 for idr@ietf.org; Fri, 02 Apr 2004 22:03:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9bR3-0006k0-00 for idr@ietf.org; Fri, 02 Apr 2004 22:03:05 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9bR2-000LIY-CX; Sat, 03 Apr 2004 03:03:04 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14514817.20040402190302@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 2 Apr 2004 19:03:02 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Steve- Thanks for looking at this. My comments inline below. I've added the IDR mailing list, since your comments cover the base spec as well. Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: > Steve, > The text explaining why the MD5 checksum is not a good candidate for > use in broader IETF protocol contexts is very well written. > The discussion of why BGP-4 can't easily change at this time to > another integrity mechanism is also very good. However, when I looked > quickly at the new BGP draft (intended to replace the extant RFC) I > was unable to find any discussion of using the MD5 option. There are > references to RFC 2385 in the discussion of what has changed, and in > the security considerations section, and the normative references > section. But a search on "MD5," "RFC 2385," "authentication," > "integrity," or "security" does not point a reader to any text that > says in any detail how to use this TCP option in the BGP context. As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP Sessions via the TCP MD5 Signature Option", in turn, describes how the option can be used to secure a TCP sessions, for BGP in particular. Is there something specific you were looking for? > The > section entitled "TCP Options that may be used with BGP" makes no > reference to it. Can someone point me to where the new BGP document > actually says how this TCP option is used? Appendix E "TCP options that may be used with BGP" could indeed mention that the MD5 option can be used for BGP sessions. Yakov, please log this. > Also, I note that the document abstract says: > "Routing information exchanged via BGP supports only the destination- > based forwarding paradigm, which assumes that a router forwards a > packet based solely on the destination address carried in the IP > header of the packet. This, in turn, reflects the set of policy > decisions that can (and can not) be enforced using BGP. BGP can > support only the policies conforming to the destination-based > forwarding paradigm." > The term "solely" seems inappropriate, since it ignores the role that > local policy plays in route selection, right? I think I know what the > authors meant to say, but the text does not seem to be correct in > this regard. It seems that the abstract is correct, actually. Routers indeed _forward_ packets using solely the destination address from the packet, as opposed to using say destination and source address, or even more granular forwarding decisions. Policies are taken into consideration when the RIB and FIB are constructed, which is not part of forwarding. > LDP is a much newer protocol and so there is less of a "large > installed base that has been using this for years" sense. We do have quite considerable installed base for LDP and strictly speaking it has been there for a few years. So, though the statement may not sound as strong when applied to LDP, it is correct. > I am also > disturbed that the LDP spec (RFC 3036) refers to this as a signature > as well, and incorporates bad text from the old BGP RFC, e.g., "... > acts like a signature for that segment .." further perpetuating the > confusion between message authentication codes and digital > signatures. Any chance we can get this fixed in both the BGP document > before it progresses and in the next rev of 3036? The BGP spec (neither old nor new) does not include this terminology, so I don't think we need to fix it from this perspective. Improvement of the LDP spec could be considered by the MPLS WG when it starts working on a new revision of the spec. Thank you. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 2 22:07:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20486 for ; Fri, 2 Apr 2004 22:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bVI-00034g-O8 for idr-archive@odin.ietf.org; Fri, 02 Apr 2004 22:07:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3337SC9011819 for idr-archive@odin.ietf.org; Fri, 2 Apr 2004 22:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bVI-00034Y-HS for idr-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 22:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20455 for ; Fri, 2 Apr 2004 22:07:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bVF-0007KF-00 for idr-web-archive@ietf.org; Fri, 02 Apr 2004 22:07:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bUH-0007CS-00 for idr-web-archive@ietf.org; Fri, 02 Apr 2004 22:06:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9bTM-00075H-00; Fri, 02 Apr 2004 22:05:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bSv-0002Wi-8P; Fri, 02 Apr 2004 22:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bSL-0002SU-Ny for idr@optimus.ietf.org; Fri, 02 Apr 2004 22:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20382 for ; Fri, 2 Apr 2004 22:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bSI-0006xZ-00 for idr@ietf.org; Fri, 02 Apr 2004 22:04:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bRU-0006r6-00 for idr@ietf.org; Fri, 02 Apr 2004 22:03:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9bR3-0006k0-00 for idr@ietf.org; Fri, 02 Apr 2004 22:03:05 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9bR2-000LIY-CX; Sat, 03 Apr 2004 03:03:04 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14514817.20040402190302@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 2 Apr 2004 19:03:02 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve- Thanks for looking at this. My comments inline below. I've added the IDR mailing list, since your comments cover the base spec as well. Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: > Steve, > The text explaining why the MD5 checksum is not a good candidate for > use in broader IETF protocol contexts is very well written. > The discussion of why BGP-4 can't easily change at this time to > another integrity mechanism is also very good. However, when I looked > quickly at the new BGP draft (intended to replace the extant RFC) I > was unable to find any discussion of using the MD5 option. There are > references to RFC 2385 in the discussion of what has changed, and in > the security considerations section, and the normative references > section. But a search on "MD5," "RFC 2385," "authentication," > "integrity," or "security" does not point a reader to any text that > says in any detail how to use this TCP option in the BGP context. As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP Sessions via the TCP MD5 Signature Option", in turn, describes how the option can be used to secure a TCP sessions, for BGP in particular. Is there something specific you were looking for? > The > section entitled "TCP Options that may be used with BGP" makes no > reference to it. Can someone point me to where the new BGP document > actually says how this TCP option is used? Appendix E "TCP options that may be used with BGP" could indeed mention that the MD5 option can be used for BGP sessions. Yakov, please log this. > Also, I note that the document abstract says: > "Routing information exchanged via BGP supports only the destination- > based forwarding paradigm, which assumes that a router forwards a > packet based solely on the destination address carried in the IP > header of the packet. This, in turn, reflects the set of policy > decisions that can (and can not) be enforced using BGP. BGP can > support only the policies conforming to the destination-based > forwarding paradigm." > The term "solely" seems inappropriate, since it ignores the role that > local policy plays in route selection, right? I think I know what the > authors meant to say, but the text does not seem to be correct in > this regard. It seems that the abstract is correct, actually. Routers indeed _forward_ packets using solely the destination address from the packet, as opposed to using say destination and source address, or even more granular forwarding decisions. Policies are taken into consideration when the RIB and FIB are constructed, which is not part of forwarding. > LDP is a much newer protocol and so there is less of a "large > installed base that has been using this for years" sense. We do have quite considerable installed base for LDP and strictly speaking it has been there for a few years. So, though the statement may not sound as strong when applied to LDP, it is correct. > I am also > disturbed that the LDP spec (RFC 3036) refers to this as a signature > as well, and incorporates bad text from the old BGP RFC, e.g., "... > acts like a signature for that segment .." further perpetuating the > confusion between message authentication codes and digital > signatures. Any chance we can get this fixed in both the BGP document > before it progresses and in the next rev of 3036? The BGP spec (neither old nor new) does not include this terminology, so I don't think we need to fix it from this perspective. Improvement of the LDP spec could be considered by the MPLS WG when it starts working on a new revision of the spec. Thank you. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 6 23:35:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00316 for ; Tue, 6 Apr 2004 23:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB3q9-00063c-00 for idr-archive@ietf.org; Tue, 06 Apr 2004 23:35:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2ZV-00075z-00 for idr-archive@ietf.org; Tue, 06 Apr 2004 22:13:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB1yn-00014a-00; Tue, 06 Apr 2004 21:35:49 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB1iy-0006XE-HA; Tue, 06 Apr 2004 21:19:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1iX-0008Ee-HB; Tue, 06 Apr 2004 21:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1hb-0007ya-Aj for idr@optimus.ietf.org; Tue, 06 Apr 2004 21:18:03 -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 VAA19410 for ; Tue, 6 Apr 2004 21:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1hY-0007F5-00 for idr@ietf.org; Tue, 06 Apr 2004 21:18:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0cZ-0000rf-00 for idr@ietf.org; Tue, 06 Apr 2004 20:08:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAzxq-00027v-00 for idr@ietf.org; Tue, 06 Apr 2004 19:26:43 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAzxo-0005Vo-8j; Tue, 06 Apr 2004 23:26:40 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <184815294.20040406162638@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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: Tue, 6 Apr 2004 16:26:38 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Steve- > the BGP document cites mandatory use of RFC 2385 as one of the > changes, up front, but then never makes any reference to the RFC in > the text. That's not a good way to communicate the intent of the > change, i.e., the intent of the change has not been integrated into > the body of the spec. It seems that you simply have missed the following reference in the "Security Considerations" section: draft-ietf-idr-bgp4-23.txt: The authentication mechanism that an implementation of BGP MUST sup- port is specified in [RFC2385]. The authentication provided by this mechanism could be done on a per peer basis. BGP vulnerabilities analysis is discussed in [BGP_VULN]. > in the context of Steve Bellovin's document there is no reason to > perpetuate the error of the RFC 2385 title, i.e., to continue to > refer to the message authentication code created by the use of a > shared secret and a hash function as a "signature." One might even > take this opportunity to point out that the title of the RFC is > misleading and should not be confused with digital signature > technologies. My understanding is that Steve used the wording from the 2385's title on purpose, since we're talking about a specific document with a specific title, plus about a TCP option with a specific name (though now considered misleading). >> > LDP is a much newer protocol and so there is less of a "large >>> installed base that has been using this for years" sense. >> >>We do have quite considerable installed base for LDP and strictly speaking it >>has been there for a few years. So, though the statement may not >>sound as strong >>when applied to LDP, it is correct. > then the text should say that LDP represents as big an installed base > as BGP's use of MD5, if that is the case. If not, then find some > accurate but similarly persuasive characterization that justifies > this use. OK. We'll see if the wording can be improved. > For contrast, RFC xxxx specifies use of MD5 in the same > fashion for OSPF security, but nobody is suggesting that this be > approved, presumably because there is no large, installed base, right? RFC 2328 includes the OSPF MD5 authentication option (similar to TCP-MD5 in its transport nature). It's widely deployed and is a full IETF Standard. If you mean "OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of only one or two implementations. >>> I am also >>> disturbed that the LDP spec (RFC 3036) refers to this as a signature >>> as well, and incorporates bad text from the old BGP RFC, e.g., "... >>> acts like a signature for that segment .." further perpetuating the >>> confusion between message authentication codes and digital >>> signatures. Any chance we can get this fixed in both the BGP document >>> before it progresses and in the next rev of 3036? >> >>The BGP spec (neither old nor new) does not include this >>terminology, so I don't >>think we need to fix it from this perspective. >> >>Improvement of the LDP spec could be considered by the MPLS WG when it starts >>working on a new revision of the spec. >> >>Thank you. >> >>Alex > you are right that the primary focus of this discussion is > progression of BGP. But, since you argued that LDP is appropriately > included in the rationale discussion for this document, I assume you > will want to progress that RFC too, > otherwise why bother mentioning it now? I would rather not have to > revisit this at that time, so I suggest you ask the MPLS WG to make a > note of this error now. Looking at the LDP spec, it uses the word "signature" as part of the reference to the "TCP MD5 Signature Option", specified in 2385. While it could be argued that 2385 uses incorrect terminology, it would be confusing to refer to it as something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication Option", as this is not what 2385 specifies. Thanks Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 6 23:35:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00539 for ; Tue, 6 Apr 2004 23:35: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 1BB3qF-0008D3-EK for idr-archive@odin.ietf.org; Tue, 06 Apr 2004 23:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i373Z7lY031557 for idr-archive@odin.ietf.org; Tue, 6 Apr 2004 23:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB3qD-0008B3-Nc for idr-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 23:35:07 -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 XAA00342 for ; Tue, 6 Apr 2004 23:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB3qB-000646-00 for idr-web-archive@ietf.org; Tue, 06 Apr 2004 23:35:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2ZZ-00076R-00 for idr-web-archive@ietf.org; Tue, 06 Apr 2004 22:13:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB1yn-00014a-00; Tue, 06 Apr 2004 21:35:49 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB1iy-0006XE-HA; Tue, 06 Apr 2004 21:19:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1iX-0008Ee-HB; Tue, 06 Apr 2004 21:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1hb-0007ya-Aj for idr@optimus.ietf.org; Tue, 06 Apr 2004 21:18:03 -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 VAA19410 for ; Tue, 6 Apr 2004 21:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1hY-0007F5-00 for idr@ietf.org; Tue, 06 Apr 2004 21:18:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0cZ-0000rf-00 for idr@ietf.org; Tue, 06 Apr 2004 20:08:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAzxq-00027v-00 for idr@ietf.org; Tue, 06 Apr 2004 19:26:43 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAzxo-0005Vo-8j; Tue, 06 Apr 2004 23:26:40 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <184815294.20040406162638@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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: Tue, 6 Apr 2004 16:26:38 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve- > the BGP document cites mandatory use of RFC 2385 as one of the > changes, up front, but then never makes any reference to the RFC in > the text. That's not a good way to communicate the intent of the > change, i.e., the intent of the change has not been integrated into > the body of the spec. It seems that you simply have missed the following reference in the "Security Considerations" section: draft-ietf-idr-bgp4-23.txt: The authentication mechanism that an implementation of BGP MUST sup- port is specified in [RFC2385]. The authentication provided by this mechanism could be done on a per peer basis. BGP vulnerabilities analysis is discussed in [BGP_VULN]. > in the context of Steve Bellovin's document there is no reason to > perpetuate the error of the RFC 2385 title, i.e., to continue to > refer to the message authentication code created by the use of a > shared secret and a hash function as a "signature." One might even > take this opportunity to point out that the title of the RFC is > misleading and should not be confused with digital signature > technologies. My understanding is that Steve used the wording from the 2385's title on purpose, since we're talking about a specific document with a specific title, plus about a TCP option with a specific name (though now considered misleading). >> > LDP is a much newer protocol and so there is less of a "large >>> installed base that has been using this for years" sense. >> >>We do have quite considerable installed base for LDP and strictly speaking it >>has been there for a few years. So, though the statement may not >>sound as strong >>when applied to LDP, it is correct. > then the text should say that LDP represents as big an installed base > as BGP's use of MD5, if that is the case. If not, then find some > accurate but similarly persuasive characterization that justifies > this use. OK. We'll see if the wording can be improved. > For contrast, RFC xxxx specifies use of MD5 in the same > fashion for OSPF security, but nobody is suggesting that this be > approved, presumably because there is no large, installed base, right? RFC 2328 includes the OSPF MD5 authentication option (similar to TCP-MD5 in its transport nature). It's widely deployed and is a full IETF Standard. If you mean "OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of only one or two implementations. >>> I am also >>> disturbed that the LDP spec (RFC 3036) refers to this as a signature >>> as well, and incorporates bad text from the old BGP RFC, e.g., "... >>> acts like a signature for that segment .." further perpetuating the >>> confusion between message authentication codes and digital >>> signatures. Any chance we can get this fixed in both the BGP document >>> before it progresses and in the next rev of 3036? >> >>The BGP spec (neither old nor new) does not include this >>terminology, so I don't >>think we need to fix it from this perspective. >> >>Improvement of the LDP spec could be considered by the MPLS WG when it starts >>working on a new revision of the spec. >> >>Thank you. >> >>Alex > you are right that the primary focus of this discussion is > progression of BGP. But, since you argued that LDP is appropriately > included in the rationale discussion for this document, I assume you > will want to progress that RFC too, > otherwise why bother mentioning it now? I would rather not have to > revisit this at that time, so I suggest you ask the MPLS WG to make a > note of this error now. Looking at the LDP spec, it uses the word "signature" as part of the reference to the "TCP MD5 Signature Option", specified in 2385. While it could be argued that 2385 uses incorrect terminology, it would be confusing to refer to it as something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication Option", as this is not what 2385 specifies. Thanks Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 7 13:20:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14025 for ; Wed, 7 Apr 2004 13:20:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGj0-0000Ff-00 for idr-archive@ietf.org; Wed, 07 Apr 2004 13:20:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFUE-0005Fe-00 for idr-archive@ietf.org; Wed, 07 Apr 2004 12:01:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBE2j-0004JF-00; Wed, 07 Apr 2004 10:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBE25-0000VC-8z; Wed, 07 Apr 2004 10: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 1BAWcD-0002uT-VY for idr@optimus.ietf.org; Mon, 05 Apr 2004 12:06:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10287 for ; Mon, 5 Apr 2004 12:06:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWcC-00048a-00 for idr@ietf.org; Mon, 05 Apr 2004 12:06:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWQ5-0002IS-00 for idr@ietf.org; Mon, 05 Apr 2004 11:53:57 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BAWEf-0000Am-00 for idr@ietf.org; Mon, 05 Apr 2004 11:42:05 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7Z015027; Mon, 5 Apr 2004 11:41:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <14514817.20040402190302@psg.com> References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> To: Alex Zinin From: Stephen Kent Cc: Steve Bellovin , saag@mit.edu, idr@ietf.org, Stephen Kent Content-Type: multipart/alternative; boundary="============_-1130942848==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 5 Apr 2004 09:49:49 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --============_-1130942848==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:03 PM -0800 4/2/04, Alex Zinin wrote: >Steve- > >Thanks for looking at this. My comments inline below. > >I've added the IDR mailing list, since your comments cover the base spec as >well. > >Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: >> Steve, > >> The text explaining why the MD5 checksum is not a good candidate for >> use in broader IETF protocol contexts is very well written. > >> The discussion of why BGP-4 can't easily change at this time to >> another integrity mechanism is also very good. However, when I looked >> quickly at the new BGP draft (intended to replace the extant RFC) I >> was unable to find any discussion of using the MD5 option. There are >> references to RFC 2385 in the discussion of what has changed, and in >> the security considerations section, and the normative references >> section. But a search on "MD5," "RFC 2385," "authentication," >> "integrity," or "security" does not point a reader to any text that >> says in any detail how to use this TCP option in the BGP context. > >As you said, the spec refers to the RFC 2385. RFC 2385 titled >"Protection of BGP >Sessions via the TCP MD5 Signature Option", in turn, describes how the option >can be used to secure a TCP sessions, for BGP in particular. Is >there something >specific you were looking for? the BGP document cites mandatory use of RFC 2385 as one of the changes, up front, but then never makes any reference to the RFC in the text. That's not a good way to communicate the intent of the change, i.e., the intent of the change has not been integrated into the body of the spec. in the context of Steve Bellovin's document there is no reason to perpetuate the error of the RFC 2385 title, i.e., to continue to refer to the message authentication code created by the use of a shared secret and a hash function as a "signature." One might even take this opportunity to point out that the title of the RFC is misleading and should not be confused with digital signature technologies. > > The >> section entitled "TCP Options that may be used with BGP" makes no >> reference to it. Can someone point me to where the new BGP document >> actually says how this TCP option is used? > >Appendix E "TCP options that may be used with BGP" could indeed >mention that the >MD5 option can be used for BGP sessions. Yakov, please log this. > >> Also, I note that the document abstract says: > >> "Routing information exchanged via BGP supports only the destination- >> based forwarding paradigm, which assumes that a router forwards a >> packet based solely on the destination address carried in the IP >> header of the packet. This, in turn, reflects the set of policy >> decisions that can (and can not) be enforced using BGP. BGP can >> support only the policies conforming to the destination-based >> forwarding paradigm." > >> The term "solely" seems inappropriate, since it ignores the role that >> local policy plays in route selection, right? I think I know what the >> authors meant to say, but the text does not seem to be correct in >> this regard. > >It seems that the abstract is correct, actually. Routers indeed _forward_ >packets using solely the destination address from the packet, as opposed to >using say destination and source address, or even more granular forwarding >decisions. Policies are taken into consideration when the RIB and FIB are >constructed, which is not part of forwarding. Good point. > > LDP is a much newer protocol and so there is less of a "large >> installed base that has been using this for years" sense. > >We do have quite considerable installed base for LDP and strictly speaking it >has been there for a few years. So, though the statement may not >sound as strong >when applied to LDP, it is correct. then the text should say that LDP represents as big an installed base as BGP's use of MD5, if that is the case. If not, then find some accurate but similarly persuasive characterization that justifies this use. For contrast, RFC xxxx specifies use of MD5 in the same fashion for OSPF security, but nobody is suggesting that this be approved, presumably because there is no large, installed base, right? > >> I am also >> disturbed that the LDP spec (RFC 3036) refers to this as a signature >> as well, and incorporates bad text from the old BGP RFC, e.g., "... >> acts like a signature for that segment .." further perpetuating the >> confusion between message authentication codes and digital >> signatures. Any chance we can get this fixed in both the BGP document >> before it progresses and in the next rev of 3036? > >The BGP spec (neither old nor new) does not include this >terminology, so I don't >think we need to fix it from this perspective. > >Improvement of the LDP spec could be considered by the MPLS WG when it starts >working on a new revision of the spec. > >Thank you. > >Alex you are right that the primary focus of this discussion is progression of BGP. But, since you argued that LDP is appropriately included in the rationale discussion for this document, I assume you will want to progress that RFC too, otherwise why bother mentioning it now? I would rather not have to revisit this at that time, so I suggest you ask the MPLS WG to make a note of this error now. Steve --============_-1130942848==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] draft-iesg-tcpmd5app-00.txt
At 7:03 PM -0800 4/2/04, Alex Zinin wrote:
Steve-

Thanks for looking at this. My comments inline below.

I've added the IDR mailing list, since your comments cover the base spec as
well.

Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> Steve,

> The text explaining why the MD5 checksum is not a good candidate for
> use in broader IETF protocol contexts is very well written.

> The discussion of why BGP-4 can't easily change at this time to
> another integrity mechanism is also very good. However, when I looked
> quickly at the new BGP draft (intended to replace the extant RFC) I
> was unable to find any discussion of using the MD5 option. There are
> references to RFC 2385 in the discussion of what has changed, and in
> the security considerations section, and the normative references
> section. But a search on "MD5," "RFC 2385," "authentication,"
> "integrity," or "security" does not point a reader to any text that
> says in any detail how to use this TCP option in the BGP context.

As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP
Sessions via the TCP MD5 Signature Option", in turn, describes how the option
can be used to secure a TCP sessions, for BGP in particular. Is there something
specific you were looking for?

the BGP document cites mandatory use of RFC 2385 as one of the changes, up front, but then never makes any reference to the RFC in the text. That's not a good way to communicate the intent of the change, i.e., the intent of the change has not been integrated into the body of the spec.

in the context of Steve Bellovin's document there is no reason to perpetuate the error of the RFC 2385 title, i.e., to continue to refer to the message authentication code created by the use of a shared secret and a hash function as a "signature."  One might even take this opportunity to point out that the title of the RFC is misleading and should not be confused with digital signature technologies.

> The
> section entitled "TCP Options that may be used with BGP" makes no
> reference to it. Can someone point me to where the new BGP document
> actually says how this TCP option is used?

Appendix E "TCP options that may be used with BGP" could indeed mention that the
MD5 option can be used for BGP sessions. Yakov, please log this.

> Also, I note that the document abstract says:

> "Routing information exchanged via BGP supports only the destination-
>     based forwarding paradigm, which assumes that a router forwards a
>     packet based solely on the destination address carried in the IP
>     header of the packet. This, in turn, reflects the set of policy
>     decisions that can (and can not) be enforced using BGP. BGP can
>     support only the policies conforming to the destination-based
>     forwarding paradigm."

> The term "solely" seems inappropriate, since it ignores the role that
> local policy plays in route selection, right? I think I know what the
> authors meant to say, but the text does not seem to be correct in
> this regard.

It seems that the abstract is correct, actually. Routers indeed _forward_
packets using solely the destination address from the packet, as opposed to
using say destination and source address, or even more granular forwarding
decisions. Policies are taken into consideration when the RIB and FIB are
constructed, which is not part of forwarding.

Good point.

> LDP is a much newer protocol and so there is less of a "large
> installed base that has been using this for years" sense.

We do have quite considerable installed base for LDP and strictly speaking it
has been there for a few years. So, though the statement may not sound as strong
when applied to LDP, it is correct.

then the text should say that LDP represents as big an installed base as BGP's use of MD5, if that is the case. If not, then find some accurate but similarly persuasive characterization that justifies this use. For contrast, RFC xxxx specifies use of MD5 in the same fashion for OSPF security, but nobody is suggesting that this be approved, presumably because there is no large, installed base, right?


>  I am also
> disturbed that the LDP spec (RFC 3036) refers to this as a signature
> as well, and incorporates bad text from the old BGP RFC, e.g., "...
> acts like a signature for that segment .." further perpetuating the
> confusion between message authentication codes and digital
> signatures. Any chance we can get this fixed in both the BGP document
> before it progresses and in the next rev of 3036?

The BGP spec (neither old nor new) does not include this terminology, so I don't
think we need to fix it from this perspective.

Improvement of the LDP spec could be considered by the MPLS WG when it starts
working on a new revision of the spec.

Thank you.

Alex

you are right that the primary focus of this discussion is progression of BGP. But, since you argued that LDP is appropriately included in the rationale discussion for this document, I assume you will want to progress that RFC too,
otherwise why bother mentioning it now?  I would rather not have to revisit this at that time, so I suggest you ask the MPLS WG to make a note of this error now.

Steve
--============_-1130942848==_ma============-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 7 13:20:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14054 for ; Wed, 7 Apr 2004 13:20:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGj2-0000G1-00 for idr-archive@ietf.org; Wed, 07 Apr 2004 13:20:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFUJ-0005G1-00 for idr-archive@ietf.org; Wed, 07 Apr 2004 12:01:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBE2j-0004JG-00; Wed, 07 Apr 2004 10:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBE24-0000V2-Nn; Wed, 07 Apr 2004 10:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bcV-0005bo-JR for idr@optimus.ietf.org; Thu, 25 Mar 2004 15:38:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19416; Thu, 25 Mar 2004 15:38:28 -0500 (EST) Message-Id: <200403252038.PAA19416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-cease-subcode-05.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: Thu, 25 Mar 2004 15:38:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-05.txt Pages : 5 Date : 2004-3-25 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-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-cease-subcode-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-cease-subcode-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: <2004-3-25154613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-25154613.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 7 13:21:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14122 for ; Wed, 7 Apr 2004 13:21: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 1BBGj4-0002Nr-66 for idr-archive@odin.ietf.org; Wed, 07 Apr 2004 13:20:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HKY7g009164 for idr-archive@odin.ietf.org; Wed, 7 Apr 2004 13:20:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGj3-0002Ni-R3 for idr-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 13:20: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 NAA14044 for ; Wed, 7 Apr 2004 13:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGj1-0000Fu-00 for idr-web-archive@ietf.org; Wed, 07 Apr 2004 13:20:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFUH-0005Ft-00 for idr-web-archive@ietf.org; Wed, 07 Apr 2004 12:01:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBE2j-0004JF-00; Wed, 07 Apr 2004 10:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBE25-0000VC-8z; Wed, 07 Apr 2004 10: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 1BAWcD-0002uT-VY for idr@optimus.ietf.org; Mon, 05 Apr 2004 12:06:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10287 for ; Mon, 5 Apr 2004 12:06:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWcC-00048a-00 for idr@ietf.org; Mon, 05 Apr 2004 12:06:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWQ5-0002IS-00 for idr@ietf.org; Mon, 05 Apr 2004 11:53:57 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BAWEf-0000Am-00 for idr@ietf.org; Mon, 05 Apr 2004 11:42:05 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7Z015027; Mon, 5 Apr 2004 11:41:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <14514817.20040402190302@psg.com> References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> To: Alex Zinin From: Stephen Kent Cc: Steve Bellovin , saag@mit.edu, idr@ietf.org, Stephen Kent Content-Type: multipart/alternative; boundary="============_-1130942848==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 5 Apr 2004 09:49:49 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --============_-1130942848==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:03 PM -0800 4/2/04, Alex Zinin wrote: >Steve- > >Thanks for looking at this. My comments inline below. > >I've added the IDR mailing list, since your comments cover the base spec as >well. > >Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: >> Steve, > >> The text explaining why the MD5 checksum is not a good candidate for >> use in broader IETF protocol contexts is very well written. > >> The discussion of why BGP-4 can't easily change at this time to >> another integrity mechanism is also very good. However, when I looked >> quickly at the new BGP draft (intended to replace the extant RFC) I >> was unable to find any discussion of using the MD5 option. There are >> references to RFC 2385 in the discussion of what has changed, and in >> the security considerations section, and the normative references >> section. But a search on "MD5," "RFC 2385," "authentication," >> "integrity," or "security" does not point a reader to any text that >> says in any detail how to use this TCP option in the BGP context. > >As you said, the spec refers to the RFC 2385. RFC 2385 titled >"Protection of BGP >Sessions via the TCP MD5 Signature Option", in turn, describes how the option >can be used to secure a TCP sessions, for BGP in particular. Is >there something >specific you were looking for? the BGP document cites mandatory use of RFC 2385 as one of the changes, up front, but then never makes any reference to the RFC in the text. That's not a good way to communicate the intent of the change, i.e., the intent of the change has not been integrated into the body of the spec. in the context of Steve Bellovin's document there is no reason to perpetuate the error of the RFC 2385 title, i.e., to continue to refer to the message authentication code created by the use of a shared secret and a hash function as a "signature." One might even take this opportunity to point out that the title of the RFC is misleading and should not be confused with digital signature technologies. > > The >> section entitled "TCP Options that may be used with BGP" makes no >> reference to it. Can someone point me to where the new BGP document >> actually says how this TCP option is used? > >Appendix E "TCP options that may be used with BGP" could indeed >mention that the >MD5 option can be used for BGP sessions. Yakov, please log this. > >> Also, I note that the document abstract says: > >> "Routing information exchanged via BGP supports only the destination- >> based forwarding paradigm, which assumes that a router forwards a >> packet based solely on the destination address carried in the IP >> header of the packet. This, in turn, reflects the set of policy >> decisions that can (and can not) be enforced using BGP. BGP can >> support only the policies conforming to the destination-based >> forwarding paradigm." > >> The term "solely" seems inappropriate, since it ignores the role that >> local policy plays in route selection, right? I think I know what the >> authors meant to say, but the text does not seem to be correct in >> this regard. > >It seems that the abstract is correct, actually. Routers indeed _forward_ >packets using solely the destination address from the packet, as opposed to >using say destination and source address, or even more granular forwarding >decisions. Policies are taken into consideration when the RIB and FIB are >constructed, which is not part of forwarding. Good point. > > LDP is a much newer protocol and so there is less of a "large >> installed base that has been using this for years" sense. > >We do have quite considerable installed base for LDP and strictly speaking it >has been there for a few years. So, though the statement may not >sound as strong >when applied to LDP, it is correct. then the text should say that LDP represents as big an installed base as BGP's use of MD5, if that is the case. If not, then find some accurate but similarly persuasive characterization that justifies this use. For contrast, RFC xxxx specifies use of MD5 in the same fashion for OSPF security, but nobody is suggesting that this be approved, presumably because there is no large, installed base, right? > >> I am also >> disturbed that the LDP spec (RFC 3036) refers to this as a signature >> as well, and incorporates bad text from the old BGP RFC, e.g., "... >> acts like a signature for that segment .." further perpetuating the >> confusion between message authentication codes and digital >> signatures. Any chance we can get this fixed in both the BGP document >> before it progresses and in the next rev of 3036? > >The BGP spec (neither old nor new) does not include this >terminology, so I don't >think we need to fix it from this perspective. > >Improvement of the LDP spec could be considered by the MPLS WG when it starts >working on a new revision of the spec. > >Thank you. > >Alex you are right that the primary focus of this discussion is progression of BGP. But, since you argued that LDP is appropriately included in the rationale discussion for this document, I assume you will want to progress that RFC too, otherwise why bother mentioning it now? I would rather not have to revisit this at that time, so I suggest you ask the MPLS WG to make a note of this error now. Steve --============_-1130942848==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] draft-iesg-tcpmd5app-00.txt
At 7:03 PM -0800 4/2/04, Alex Zinin wrote:
Steve-

Thanks for looking at this. My comments inline below.

I've added the IDR mailing list, since your comments cover the base spec as
well.

Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> Steve,

> The text explaining why the MD5 checksum is not a good candidate for
> use in broader IETF protocol contexts is very well written.

> The discussion of why BGP-4 can't easily change at this time to
> another integrity mechanism is also very good. However, when I looked
> quickly at the new BGP draft (intended to replace the extant RFC) I
> was unable to find any discussion of using the MD5 option. There are
> references to RFC 2385 in the discussion of what has changed, and in
> the security considerations section, and the normative references
> section. But a search on "MD5," "RFC 2385," "authentication,"
> "integrity," or "security" does not point a reader to any text that
> says in any detail how to use this TCP option in the BGP context.

As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP
Sessions via the TCP MD5 Signature Option", in turn, describes how the option
can be used to secure a TCP sessions, for BGP in particular. Is there something
specific you were looking for?

the BGP document cites mandatory use of RFC 2385 as one of the changes, up front, but then never makes any reference to the RFC in the text. That's not a good way to communicate the intent of the change, i.e., the intent of the change has not been integrated into the body of the spec.

in the context of Steve Bellovin's document there is no reason to perpetuate the error of the RFC 2385 title, i.e., to continue to refer to the message authentication code created by the use of a shared secret and a hash function as a "signature."  One might even take this opportunity to point out that the title of the RFC is misleading and should not be confused with digital signature technologies.

> The
> section entitled "TCP Options that may be used with BGP" makes no
> reference to it. Can someone point me to where the new BGP document
> actually says how this TCP option is used?

Appendix E "TCP options that may be used with BGP" could indeed mention that the
MD5 option can be used for BGP sessions. Yakov, please log this.

> Also, I note that the document abstract says:

> "Routing information exchanged via BGP supports only the destination-
>     based forwarding paradigm, which assumes that a router forwards a
>     packet based solely on the destination address carried in the IP
>     header of the packet. This, in turn, reflects the set of policy
>     decisions that can (and can not) be enforced using BGP. BGP can
>     support only the policies conforming to the destination-based
>     forwarding paradigm."

> The term "solely" seems inappropriate, since it ignores the role that
> local policy plays in route selection, right? I think I know what the
> authors meant to say, but the text does not seem to be correct in
> this regard.

It seems that the abstract is correct, actually. Routers indeed _forward_
packets using solely the destination address from the packet, as opposed to
using say destination and source address, or even more granular forwarding
decisions. Policies are taken into consideration when the RIB and FIB are
constructed, which is not part of forwarding.

Good point.

> LDP is a much newer protocol and so there is less of a "large
> installed base that has been using this for years" sense.

We do have quite considerable installed base for LDP and strictly speaking it
has been there for a few years. So, though the statement may not sound as strong
when applied to LDP, it is correct.

then the text should say that LDP represents as big an installed base as BGP's use of MD5, if that is the case. If not, then find some accurate but similarly persuasive characterization that justifies this use. For contrast, RFC xxxx specifies use of MD5 in the same fashion for OSPF security, but nobody is suggesting that this be approved, presumably because there is no large, installed base, right?


>  I am also
> disturbed that the LDP spec (RFC 3036) refers to this as a signature
> as well, and incorporates bad text from the old BGP RFC, e.g., "...
> acts like a signature for that segment .." further perpetuating the
> confusion between message authentication codes and digital
> signatures. Any chance we can get this fixed in both the BGP document
> before it progresses and in the next rev of 3036?

The BGP spec (neither old nor new) does not include this terminology, so I don't
think we need to fix it from this perspective.

Improvement of the LDP spec could be considered by the MPLS WG when it starts
working on a new revision of the spec.

Thank you.

Alex

you are right that the primary focus of this discussion is progression of BGP. But, since you argued that LDP is appropriately included in the rationale discussion for this document, I assume you will want to progress that RFC too,
otherwise why bother mentioning it now?  I would rather not have to revisit this at that time, so I suggest you ask the MPLS WG to make a note of this error now.

Steve
--============_-1130942848==_ma============-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 7 13:21:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14141 for ; Wed, 7 Apr 2004 13:21: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 1BBGj5-0002Ox-UL for idr-archive@odin.ietf.org; Wed, 07 Apr 2004 13:20:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HKZwx009227 for idr-archive@odin.ietf.org; Wed, 7 Apr 2004 13:20:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGj5-0002Ok-QX for idr-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 13:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14081 for ; Wed, 7 Apr 2004 13:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGj3-0000GD-00 for idr-web-archive@ietf.org; Wed, 07 Apr 2004 13:20:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFUL-0005GG-00 for idr-web-archive@ietf.org; Wed, 07 Apr 2004 12:01:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBE2j-0004JG-00; Wed, 07 Apr 2004 10:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBE24-0000V2-Nn; Wed, 07 Apr 2004 10:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bcV-0005bo-JR for idr@optimus.ietf.org; Thu, 25 Mar 2004 15:38:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19416; Thu, 25 Mar 2004 15:38:28 -0500 (EST) Message-Id: <200403252038.PAA19416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-cease-subcode-05.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: Thu, 25 Mar 2004 15:38:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-05.txt Pages : 5 Date : 2004-3-25 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-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-cease-subcode-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-cease-subcode-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: <2004-3-25154613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-25154613.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 7 13:55:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19750 for ; Wed, 7 Apr 2004 13:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHGV-0005aj-00 for idr-archive@ietf.org; Wed, 07 Apr 2004 13:55:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGR7-0004qa-00 for idr-archive@ietf.org; Wed, 07 Apr 2004 13:02:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBExr-0002Ti-00; Wed, 07 Apr 2004 11:27:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBEcA-0000Kp-IV; Wed, 07 Apr 2004 11:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAt4w-0003fE-28 for idr@optimus.ietf.org; Tue, 06 Apr 2004 12:05:34 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00946 for ; Tue, 6 Apr 2004 12:05:30 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAt4C-0003W6-Hp; Tue, 06 Apr 2004 12:04:48 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Idr] Last Call: 'BGP Extended Communities Attribute' to Proposed Standard 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, 06 Apr 2004 12:04:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the Inter-Domain Routing WG to consider the following document: - 'BGP Extended Communities Attribute ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-20. The implementation report can be found in the accompanying document: - 'BGP Extended Communities Attribute - Implementation Survey' The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities- 07.txt http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey- 02.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 7 13:55:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19928 for ; Wed, 7 Apr 2004 13:55: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 1BBHGZ-0003Ps-Ih for idr-archive@odin.ietf.org; Wed, 07 Apr 2004 13:55:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HtBjs013126 for idr-archive@odin.ietf.org; Wed, 7 Apr 2004 13:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHGZ-0003Pd-DY for idr-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 13:55: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 NAA19777 for ; Wed, 7 Apr 2004 13:55:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHGW-0005b0-00 for idr-web-archive@ietf.org; Wed, 07 Apr 2004 13:55:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGRA-0004rG-00 for idr-web-archive@ietf.org; Wed, 07 Apr 2004 13:02:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBExr-0002Ti-00; Wed, 07 Apr 2004 11:27:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBEcA-0000Kp-IV; Wed, 07 Apr 2004 11:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAt4w-0003fE-28 for idr@optimus.ietf.org; Tue, 06 Apr 2004 12:05:34 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00946 for ; Tue, 6 Apr 2004 12:05:30 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAt4C-0003W6-Hp; Tue, 06 Apr 2004 12:04:48 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Idr] Last Call: 'BGP Extended Communities Attribute' to Proposed Standard 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, 06 Apr 2004 12:04:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the Inter-Domain Routing WG to consider the following document: - 'BGP Extended Communities Attribute ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-20. The implementation report can be found in the accompanying document: - 'BGP Extended Communities Attribute - Implementation Survey' The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities- 07.txt http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey- 02.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 8 21:24:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20327 for ; Thu, 8 Apr 2004 21:24:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBklA-0001XF-00 for idr-archive@ietf.org; Thu, 08 Apr 2004 21:24:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkVm-0000H0-00 for idr-archive@ietf.org; Thu, 08 Apr 2004 21:08:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBkFp-0005ts-00; Thu, 08 Apr 2004 20:52:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkFV-0008Fy-Is; Thu, 08 Apr 2004 20:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkEu-0008EF-Mf for idr@optimus.ietf.org; Thu, 08 Apr 2004 20:51: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 UAA17246 for ; Thu, 8 Apr 2004 20:51:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkEr-0005h2-00 for idr@ietf.org; Thu, 08 Apr 2004 20:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBjsb-0002yp-00 for idr@ietf.org; Thu, 08 Apr 2004 20:28:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjJY-0006zW-00 for idr@ietf.org; Thu, 08 Apr 2004 19:52:08 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjJW-0006qH-4J; Thu, 08 Apr 2004 23:52:06 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1171876158.20040408165204@psg.com> To: idr@ietf.org CC: Stephen Kent , Steve Bellovin In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 16:52:04 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit This is a forwarded message From: Stephen Kent To: Alex Zinin Cc: Steve Bellovin , saag@mit.edu Date: Wednesday, April 7, 2004, 8:09:53 AM Subject: [saag] draft-iesg-tcpmd5app-00.txt ===8<==============Original message text=============== At 4:26 PM -0700 4/6/04, Alex Zinin wrote: >Steve- > >> the BGP document cites mandatory use of RFC 2385 as one of the >> changes, up front, but then never makes any reference to the RFC in >> the text. That's not a good way to communicate the intent of the >> change, i.e., the intent of the change has not been integrated into >> the body of the spec. > >It seems that you simply have missed the following reference in the "Security >Considerations" section: > > draft-ietf-idr-bgp4-23.txt: > > The authentication mechanism that an implementation of BGP MUST sup- > port is specified in [RFC2385]. The authentication provided by this > mechanism could be done on a per peer basis. > > BGP vulnerabilities analysis is discussed in [BGP_VULN]. No, I didn't miss it, Alex. I consider it a trivial reference that fails to do an adequate job. The Security Considerations section of a document is not where one first specifies a requirement for a protocol. It is a place to comment upon what has already been specified, putting it in context relative to security. > > in the context of Steve Bellovin's document there is no reason to >> perpetuate the error of the RFC 2385 title, i.e., to continue to >> refer to the message authentication code created by the use of a >> shared secret and a hash function as a "signature." One might even >> take this opportunity to point out that the title of the RFC is >> misleading and should not be confused with digital signature >> technologies. > >My understanding is that Steve used the wording from the 2385's title on >purpose, since we're talking about a specific document with a specific title, >plus about a TCP option with a specific name (though now considered >misleading). Alex, the terminology was always wrong, and I pointed that out to the IESG when the RFC was out for last call years ago. But Jeff Schiller apparently didn't think the terminology error was worth fixing, and I doubt that the rest of the IESG was concerned back then. Don't phrase this as though we're in the realm of revisionist political correctness. It was wrong then, and it's still wrong. > > >> For contrast, RFC xxxx specifies use of MD5 in the same >> fashion for OSPF security, but nobody is suggesting that this be >> approved, presumably because there is no large, installed base, right? > >RFC 2328 includes the OSPF MD5 authentication option (similar to >TCP-MD5 in its >transport nature). It's widely deployed and is a full IETF Standard. >If you mean >"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of >only one or two implementations. Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, I was referring to 2238. We have a slightly odd situation here. Steve's document explains why BGP is being progressed even though it contains a normative reference to an RFC (TCP MD5 ...) that will not be progressed. The argument is that the latter RFC is technically poor, but it's not so awful to use it with BGP considering the context, because it is widely deployed, and because it is the only point-to-point authentication mechanism defined for BGP. Then there is the minor mention of LDP at te end. You suggest, above, that OSPF's use of MD5 is also widely deployed, something of which I was not aware. (Or did you just mean that many OSPF implementations support the feature, but you don't know if it is tuend on?) OSPF does not use the TCP MD5 option, but rather uses MD5 in the same marginal way internally. So, in one sense there is no need to mention this in Steve's document, because it is just explaining why the IESG is making an exception for BGP, and LDP in the future. But, in a more fundamental sense, we have already endorsed the inappropriate use of MD5 in routing protocols in terms of OSPF, and we're merely continuing the tradition with BGP and LDP :-). > > you are right that the primary focus of this discussion is > > progression of BGP. But, since you argued that LDP is appropriately > > included in the rationale discussion for this document, I assume you > > will want to progress that RFC too, > > otherwise why bother mentioning it now? I would rather not have to > > revisit this at that time, so I suggest you ask the MPLS WG to make a > > note of this error now. > >Looking at the LDP spec, it uses the word "signature" as part of the reference >to the "TCP MD5 Signature Option", specified in 2385. While it could be argued >that 2385 uses incorrect terminology, it would be confusing to refer to it as >something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication >Option", as this is not what 2385 specifies. If you look at Steve's document, he uses the right terminology throughout, while referring to the document via its RFC number. That's a good model for any document that wants to avoid perpetuating the terminology error inherent in the title of 2385. Steve ===8<===========End of original message text=========== _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 8 21:25:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20450 for ; Thu, 8 Apr 2004 21:25:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBklG-0003uC-NB for idr-archive@odin.ietf.org; Thu, 08 Apr 2004 21:24:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391Oom3015008 for idr-archive@odin.ietf.org; Thu, 8 Apr 2004 21:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBklG-0003tz-D4 for idr-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:24: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 VAA20374 for ; Thu, 8 Apr 2004 21:24:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBklD-0001Xb-00 for idr-web-archive@ietf.org; Thu, 08 Apr 2004 21:24:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkVp-0000HS-00 for idr-web-archive@ietf.org; Thu, 08 Apr 2004 21:08:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBkFp-0005ts-00; Thu, 08 Apr 2004 20:52:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkFV-0008Fy-Is; Thu, 08 Apr 2004 20:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkEu-0008EF-Mf for idr@optimus.ietf.org; Thu, 08 Apr 2004 20:51: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 UAA17246 for ; Thu, 8 Apr 2004 20:51:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkEr-0005h2-00 for idr@ietf.org; Thu, 08 Apr 2004 20:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBjsb-0002yp-00 for idr@ietf.org; Thu, 08 Apr 2004 20:28:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjJY-0006zW-00 for idr@ietf.org; Thu, 08 Apr 2004 19:52:08 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjJW-0006qH-4J; Thu, 08 Apr 2004 23:52:06 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1171876158.20040408165204@psg.com> To: idr@ietf.org CC: Stephen Kent , Steve Bellovin In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 16:52:04 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit This is a forwarded message From: Stephen Kent To: Alex Zinin Cc: Steve Bellovin , saag@mit.edu Date: Wednesday, April 7, 2004, 8:09:53 AM Subject: [saag] draft-iesg-tcpmd5app-00.txt ===8<==============Original message text=============== At 4:26 PM -0700 4/6/04, Alex Zinin wrote: >Steve- > >> the BGP document cites mandatory use of RFC 2385 as one of the >> changes, up front, but then never makes any reference to the RFC in >> the text. That's not a good way to communicate the intent of the >> change, i.e., the intent of the change has not been integrated into >> the body of the spec. > >It seems that you simply have missed the following reference in the "Security >Considerations" section: > > draft-ietf-idr-bgp4-23.txt: > > The authentication mechanism that an implementation of BGP MUST sup- > port is specified in [RFC2385]. The authentication provided by this > mechanism could be done on a per peer basis. > > BGP vulnerabilities analysis is discussed in [BGP_VULN]. No, I didn't miss it, Alex. I consider it a trivial reference that fails to do an adequate job. The Security Considerations section of a document is not where one first specifies a requirement for a protocol. It is a place to comment upon what has already been specified, putting it in context relative to security. > > in the context of Steve Bellovin's document there is no reason to >> perpetuate the error of the RFC 2385 title, i.e., to continue to >> refer to the message authentication code created by the use of a >> shared secret and a hash function as a "signature." One might even >> take this opportunity to point out that the title of the RFC is >> misleading and should not be confused with digital signature >> technologies. > >My understanding is that Steve used the wording from the 2385's title on >purpose, since we're talking about a specific document with a specific title, >plus about a TCP option with a specific name (though now considered >misleading). Alex, the terminology was always wrong, and I pointed that out to the IESG when the RFC was out for last call years ago. But Jeff Schiller apparently didn't think the terminology error was worth fixing, and I doubt that the rest of the IESG was concerned back then. Don't phrase this as though we're in the realm of revisionist political correctness. It was wrong then, and it's still wrong. > > >> For contrast, RFC xxxx specifies use of MD5 in the same >> fashion for OSPF security, but nobody is suggesting that this be >> approved, presumably because there is no large, installed base, right? > >RFC 2328 includes the OSPF MD5 authentication option (similar to >TCP-MD5 in its >transport nature). It's widely deployed and is a full IETF Standard. >If you mean >"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of >only one or two implementations. Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, I was referring to 2238. We have a slightly odd situation here. Steve's document explains why BGP is being progressed even though it contains a normative reference to an RFC (TCP MD5 ...) that will not be progressed. The argument is that the latter RFC is technically poor, but it's not so awful to use it with BGP considering the context, because it is widely deployed, and because it is the only point-to-point authentication mechanism defined for BGP. Then there is the minor mention of LDP at te end. You suggest, above, that OSPF's use of MD5 is also widely deployed, something of which I was not aware. (Or did you just mean that many OSPF implementations support the feature, but you don't know if it is tuend on?) OSPF does not use the TCP MD5 option, but rather uses MD5 in the same marginal way internally. So, in one sense there is no need to mention this in Steve's document, because it is just explaining why the IESG is making an exception for BGP, and LDP in the future. But, in a more fundamental sense, we have already endorsed the inappropriate use of MD5 in routing protocols in terms of OSPF, and we're merely continuing the tradition with BGP and LDP :-). > > you are right that the primary focus of this discussion is > > progression of BGP. But, since you argued that LDP is appropriately > > included in the rationale discussion for this document, I assume you > > will want to progress that RFC too, > > otherwise why bother mentioning it now? I would rather not have to > > revisit this at that time, so I suggest you ask the MPLS WG to make a > > note of this error now. > >Looking at the LDP spec, it uses the word "signature" as part of the reference >to the "TCP MD5 Signature Option", specified in 2385. While it could be argued >that 2385 uses incorrect terminology, it would be confusing to refer to it as >something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication >Option", as this is not what 2385 specifies. If you look at Steve's document, he uses the right terminology throughout, while referring to the document via its RFC number. That's a good model for any document that wants to avoid perpetuating the terminology error inherent in the title of 2385. Steve ===8<===========End of original message text=========== _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 8 21:25:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20467 for ; Thu, 8 Apr 2004 21:25:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBklM-0003uS-2d for idr-archive@odin.ietf.org; Thu, 08 Apr 2004 21:24:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391Oufk015024 for idr-archive@odin.ietf.org; Thu, 8 Apr 2004 21:24:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBklL-0003uF-U3 for idr-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:24: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 VAA20382 for ; Thu, 8 Apr 2004 21:24:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBklE-0001Xi-00 for idr-web-archive@ietf.org; Thu, 08 Apr 2004 21:24:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkVq-0000Hc-00 for idr-web-archive@ietf.org; Thu, 08 Apr 2004 21:08:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBkFp-0005tu-00; Thu, 08 Apr 2004 20:52:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkFW-0008G6-2I; Thu, 08 Apr 2004 20:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkEw-0008EK-2n for idr@optimus.ietf.org; Thu, 08 Apr 2004 20:51:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17250 for ; Thu, 8 Apr 2004 20:51:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkEt-0005hQ-00 for idr@ietf.org; Thu, 08 Apr 2004 20:51:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBjsg-0002zx-00 for idr@ietf.org; Thu, 08 Apr 2004 20:28:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjJj-000722-00 for idr@ietf.org; Thu, 08 Apr 2004 19:52:19 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjJj-0006xe-L9; Thu, 08 Apr 2004 23:52:19 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5810329073.20040408165218@psg.com> To: idr@ietf.org CC: Stephen Kent , Steve Bellovin In-Reply-To: <20040407151311.9FA417B44@berkshire.research.att.com> References: Your message of "Wed, 07 Apr 2004 11:09:53 EDT." <20040407151311.9FA417B44@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 16:52:18 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit This is a forwarded message From: Steven M. Bellovin To: Stephen Kent Cc: Alex Zinin , saag@mit.edu Date: Wednesday, April 7, 2004, 8:13:10 AM Subject: [saag] draft-iesg-tcpmd5app-00.txt ===8<==============Original message text=============== In message , Stephen Kent writes: >If you look at Steve's document, he uses the right terminology >throughout, while referring to the document via its RFC number. >That's a good model for any document that wants to avoid perpetuating >the terminology error inherent in the title of 2385. > It's probably worth putting a note in my document noting the erroneous terminology in the title of 2385. It's not a bad idea having a similar parenthetical note in the bgp document. --Steve Bellovin, http://www.research.att.com/~smb ===8<===========End of original message text=========== _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 8 21:31:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20710 for ; Thu, 8 Apr 2004 21:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkrI-000259-00 for idr-archive@ietf.org; Thu, 08 Apr 2004 21:31:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkiS-0001FB-00 for idr-archive@ietf.org; Thu, 08 Apr 2004 21:21:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBkOF-0007RL-00; Thu, 08 Apr 2004 21:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkOE-0000mQ-Er; Thu, 08 Apr 2004 21:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkNk-0000ks-HX for idr@optimus.ietf.org; Thu, 08 Apr 2004 21:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17812 for ; Thu, 8 Apr 2004 21:00:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkNh-0007OB-00 for idr@ietf.org; Thu, 08 Apr 2004 21:00:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBk9g-0004kc-00 for idr@ietf.org; Thu, 08 Apr 2004 20:46:01 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjgd-0001vY-00 for idr@ietf.org; Thu, 08 Apr 2004 20:15:59 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjgb-000J8k-1f; Fri, 09 Apr 2004 00:15:57 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1653165747.20040408171556@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 17:15:56 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Steve- [putting IDR back on the Cc: list--I'd like the WG to be in the loop] Wednesday, April 7, 2004, 8:09:53 AM, Stephen Kent wrote: > At 4:26 PM -0700 4/6/04, Alex Zinin wrote: >>Steve- >> >>> the BGP document cites mandatory use of RFC 2385 as one of the >>> changes, up front, but then never makes any reference to the RFC in >>> the text. That's not a good way to communicate the intent of the >>> change, i.e., the intent of the change has not been integrated into >>> the body of the spec. >> >>It seems that you simply have missed the following reference in the "Security >>Considerations" section: >> >> draft-ietf-idr-bgp4-23.txt: >> >> The authentication mechanism that an implementation of BGP MUST sup- >> port is specified in [RFC2385]. The authentication provided by this >> mechanism could be done on a per peer basis. >> >> BGP vulnerabilities analysis is discussed in [BGP_VULN]. > No, I didn't miss it, Alex. I consider it a trivial reference that > fails to do an adequate job. The Security Considerations section of a > document is not where one first specifies a requirement for a > protocol. It is a place to comment upon what has already been > specified, putting it in context relative to security. Steve, would you mind making a suggestion on how the text could be improved? E.g., would a separate section in the main body of the document specifying the requirement for TCP-MD5 support be useful? >> > in the context of Steve Bellovin's document there is no reason to >>> perpetuate the error of the RFC 2385 title, i.e., to continue to >>> refer to the message authentication code created by the use of a >>> shared secret and a hash function as a "signature." One might even >>> take this opportunity to point out that the title of the RFC is >>> misleading and should not be confused with digital signature >>> technologies. >> >>My understanding is that Steve used the wording from the 2385's title on >>purpose, since we're talking about a specific document with a specific title, >>plus about a TCP option with a specific name (though now considered >>misleading). > Alex, the terminology was always wrong, and I pointed that out to the > IESG when the RFC was out for last call years ago. But Jeff Schiller > apparently didn't think the terminology error was worth fixing, and I > doubt that the rest of the IESG was concerned back then. Don't phrase > this as though we're in the realm of revisionist political > correctness. It was wrong then, and it's still wrong. I didn't mean to argue whether the terminology is right or wrong, I'll leave up to you guys. My point was that we have to use the actual title of the document when referring to it, even though the title may not accurately describe what's inside. Anyway, Steve suggested that a clarifying note is put in the docs... >> >> >>> For contrast, RFC xxxx specifies use of MD5 in the same >>> fashion for OSPF security, but nobody is suggesting that this be >>> approved, presumably because there is no large, installed base, right? >> >>RFC 2328 includes the OSPF MD5 authentication option (similar to >>TCP-MD5 in its >>transport nature). It's widely deployed and is a full IETF Standard. >>If you mean >>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of >>only one or two implementations. > Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, > I was referring to 2238. We have a slightly odd situation here. > Steve's document explains why BGP is being progressed even though it > contains a normative reference to an RFC (TCP MD5 ...) that will not > be progressed. The argument is that the latter RFC is technically > poor, but it's not so awful to use it with BGP considering the > context, because it is widely deployed, and because it is the only > point-to-point authentication mechanism defined for BGP. Then there > is the minor mention of LDP at te end. > You suggest, above, that OSPF's use of MD5 is also widely deployed, > something of which I was not aware. (Or did you just mean that many > OSPF implementations support the feature, but you don't know if it is > tuend on?) All more-or-less mature OSPF implementations I know of certainly support the feature. As for deployment, OSPF MD5 _is_ being used in both SP and enterprise networks. I do not have numbers for you, but even as of 3-4 years ago (when I worked close with operators on a regular basis), it was not uncommon to see it configured. > OSPF does not use the TCP MD5 option, but rather uses MD5 > in the same marginal way internally. So, in one sense there is no > need to mention this in Steve's document, because it is just > explaining why the IESG is making an exception for BGP, and LDP in > the future. Agreed. > But, in a more fundamental sense, we have already > endorsed the inappropriate use of MD5 in routing protocols in terms > of OSPF, and we're merely continuing the tradition with BGP and LDP > :-). It seems a discussion on why MD5 is inappropriate or insufficient in routing protocols would be interesting if we take it to RPSEC. Thanks. Alex > >> > you are right that the primary focus of this discussion is >> > progression of BGP. But, since you argued that LDP is appropriately >> > included in the rationale discussion for this document, I assume you >> > will want to progress that RFC too, >> > otherwise why bother mentioning it now? I would rather not have to >> > revisit this at that time, so I suggest you ask the MPLS WG to make a >> > note of this error now. >> >>Looking at the LDP spec, it uses the word "signature" as part of the reference >>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued >>that 2385 uses incorrect terminology, it would be confusing to refer to it as >>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication >>Option", as this is not what 2385 specifies. > If you look at Steve's document, he uses the right terminology > throughout, while referring to the document via its RFC number. > That's a good model for any document that wants to avoid perpetuating > the terminology error inherent in the title of 2385. > Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 8 21:31:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20768 for ; Thu, 8 Apr 2004 21:31:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkrW-0004TX-LZ for idr-archive@odin.ietf.org; Thu, 08 Apr 2004 21:31:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391VIRK017203 for idr-archive@odin.ietf.org; Thu, 8 Apr 2004 21:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkrW-0004TO-Gl for idr-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:31:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20740 for ; Thu, 8 Apr 2004 21:31:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkrT-00025a-00 for idr-web-archive@ietf.org; Thu, 08 Apr 2004 21:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkiX-0001Fr-00 for idr-web-archive@ietf.org; Thu, 08 Apr 2004 21:22:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBkOF-0007RL-00; Thu, 08 Apr 2004 21:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkOE-0000mQ-Er; Thu, 08 Apr 2004 21:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkNk-0000ks-HX for idr@optimus.ietf.org; Thu, 08 Apr 2004 21:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17812 for ; Thu, 8 Apr 2004 21:00:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkNh-0007OB-00 for idr@ietf.org; Thu, 08 Apr 2004 21:00:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBk9g-0004kc-00 for idr@ietf.org; Thu, 08 Apr 2004 20:46:01 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjgd-0001vY-00 for idr@ietf.org; Thu, 08 Apr 2004 20:15:59 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjgb-000J8k-1f; Fri, 09 Apr 2004 00:15:57 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1653165747.20040408171556@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 17:15:56 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Steve- [putting IDR back on the Cc: list--I'd like the WG to be in the loop] Wednesday, April 7, 2004, 8:09:53 AM, Stephen Kent wrote: > At 4:26 PM -0700 4/6/04, Alex Zinin wrote: >>Steve- >> >>> the BGP document cites mandatory use of RFC 2385 as one of the >>> changes, up front, but then never makes any reference to the RFC in >>> the text. That's not a good way to communicate the intent of the >>> change, i.e., the intent of the change has not been integrated into >>> the body of the spec. >> >>It seems that you simply have missed the following reference in the "Security >>Considerations" section: >> >> draft-ietf-idr-bgp4-23.txt: >> >> The authentication mechanism that an implementation of BGP MUST sup- >> port is specified in [RFC2385]. The authentication provided by this >> mechanism could be done on a per peer basis. >> >> BGP vulnerabilities analysis is discussed in [BGP_VULN]. > No, I didn't miss it, Alex. I consider it a trivial reference that > fails to do an adequate job. The Security Considerations section of a > document is not where one first specifies a requirement for a > protocol. It is a place to comment upon what has already been > specified, putting it in context relative to security. Steve, would you mind making a suggestion on how the text could be improved? E.g., would a separate section in the main body of the document specifying the requirement for TCP-MD5 support be useful? >> > in the context of Steve Bellovin's document there is no reason to >>> perpetuate the error of the RFC 2385 title, i.e., to continue to >>> refer to the message authentication code created by the use of a >>> shared secret and a hash function as a "signature." One might even >>> take this opportunity to point out that the title of the RFC is >>> misleading and should not be confused with digital signature >>> technologies. >> >>My understanding is that Steve used the wording from the 2385's title on >>purpose, since we're talking about a specific document with a specific title, >>plus about a TCP option with a specific name (though now considered >>misleading). > Alex, the terminology was always wrong, and I pointed that out to the > IESG when the RFC was out for last call years ago. But Jeff Schiller > apparently didn't think the terminology error was worth fixing, and I > doubt that the rest of the IESG was concerned back then. Don't phrase > this as though we're in the realm of revisionist political > correctness. It was wrong then, and it's still wrong. I didn't mean to argue whether the terminology is right or wrong, I'll leave up to you guys. My point was that we have to use the actual title of the document when referring to it, even though the title may not accurately describe what's inside. Anyway, Steve suggested that a clarifying note is put in the docs... >> >> >>> For contrast, RFC xxxx specifies use of MD5 in the same >>> fashion for OSPF security, but nobody is suggesting that this be >>> approved, presumably because there is no large, installed base, right? >> >>RFC 2328 includes the OSPF MD5 authentication option (similar to >>TCP-MD5 in its >>transport nature). It's widely deployed and is a full IETF Standard. >>If you mean >>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of >>only one or two implementations. > Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, > I was referring to 2238. We have a slightly odd situation here. > Steve's document explains why BGP is being progressed even though it > contains a normative reference to an RFC (TCP MD5 ...) that will not > be progressed. The argument is that the latter RFC is technically > poor, but it's not so awful to use it with BGP considering the > context, because it is widely deployed, and because it is the only > point-to-point authentication mechanism defined for BGP. Then there > is the minor mention of LDP at te end. > You suggest, above, that OSPF's use of MD5 is also widely deployed, > something of which I was not aware. (Or did you just mean that many > OSPF implementations support the feature, but you don't know if it is > tuend on?) All more-or-less mature OSPF implementations I know of certainly support the feature. As for deployment, OSPF MD5 _is_ being used in both SP and enterprise networks. I do not have numbers for you, but even as of 3-4 years ago (when I worked close with operators on a regular basis), it was not uncommon to see it configured. > OSPF does not use the TCP MD5 option, but rather uses MD5 > in the same marginal way internally. So, in one sense there is no > need to mention this in Steve's document, because it is just > explaining why the IESG is making an exception for BGP, and LDP in > the future. Agreed. > But, in a more fundamental sense, we have already > endorsed the inappropriate use of MD5 in routing protocols in terms > of OSPF, and we're merely continuing the tradition with BGP and LDP > :-). It seems a discussion on why MD5 is inappropriate or insufficient in routing protocols would be interesting if we take it to RPSEC. Thanks. Alex > >> > you are right that the primary focus of this discussion is >> > progression of BGP. But, since you argued that LDP is appropriately >> > included in the rationale discussion for this document, I assume you >> > will want to progress that RFC too, >> > otherwise why bother mentioning it now? I would rather not have to >> > revisit this at that time, so I suggest you ask the MPLS WG to make a >> > note of this error now. >> >>Looking at the LDP spec, it uses the word "signature" as part of the reference >>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued >>that 2385 uses incorrect terminology, it would be confusing to refer to it as >>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication >>Option", as this is not what 2385 specifies. > If you look at Steve's document, he uses the right terminology > throughout, while referring to the document via its RFC number. > That's a good model for any document that wants to avoid perpetuating > the terminology error inherent in the title of 2385. > Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 8 22:10:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20344 for ; Thu, 8 Apr 2004 21:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBklB-0001XK-00 for idr-archive@ietf.org; Thu, 08 Apr 2004 21:24:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkVn-0000HA-00 for idr-archive@ietf.org; Thu, 08 Apr 2004 21:08:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBkFp-0005tu-00; Thu, 08 Apr 2004 20:52:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkFW-0008G6-2I; Thu, 08 Apr 2004 20:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkEw-0008EK-2n for idr@optimus.ietf.org; Thu, 08 Apr 2004 20:51:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17250 for ; Thu, 8 Apr 2004 20:51:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkEt-0005hQ-00 for idr@ietf.org; Thu, 08 Apr 2004 20:51:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBjsg-0002zx-00 for idr@ietf.org; Thu, 08 Apr 2004 20:28:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjJj-000722-00 for idr@ietf.org; Thu, 08 Apr 2004 19:52:19 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjJj-0006xe-L9; Thu, 08 Apr 2004 23:52:19 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5810329073.20040408165218@psg.com> To: idr@ietf.org CC: Stephen Kent , Steve Bellovin In-Reply-To: <20040407151311.9FA417B44@berkshire.research.att.com> References: Your message of "Wed, 07 Apr 2004 11:09:53 EDT." <20040407151311.9FA417B44@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 16:52:18 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit This is a forwarded message From: Steven M. Bellovin To: Stephen Kent Cc: Alex Zinin , saag@mit.edu Date: Wednesday, April 7, 2004, 8:13:10 AM Subject: [saag] draft-iesg-tcpmd5app-00.txt ===8<==============Original message text=============== In message , Stephen Kent writes: >If you look at Steve's document, he uses the right terminology >throughout, while referring to the document via its RFC number. >That's a good model for any document that wants to avoid perpetuating >the terminology error inherent in the title of 2385. > It's probably worth putting a note in my document noting the erroneous terminology in the title of 2385. It's not a bad idea having a similar parenthetical note in the bgp document. --Steve Bellovin, http://www.research.att.com/~smb ===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 Apr 12 12:12:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26787 for ; Mon, 12 Apr 2004 12:12:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD42t-0004uB-00 for idr-archive@ietf.org; Mon, 12 Apr 2004 12:12:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD41W-0004fq-00 for idr-archive@ietf.org; Mon, 12 Apr 2004 12:11:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD3zu-0004WR-00; Mon, 12 Apr 2004 12:09:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3za-0006MP-H3; Mon, 12 Apr 2004 12:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByHe-0006mN-UB for idr@optimus.ietf.org; Fri, 09 Apr 2004 11:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03555 for ; Fri, 9 Apr 2004 11:51:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByHd-0001gu-00 for idr@ietf.org; Fri, 09 Apr 2004 11:51:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByGB-0001ZP-00 for idr@ietf.org; Fri, 09 Apr 2004 11:49:40 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BByEy-0001Mk-00 for idr@ietf.org; Fri, 09 Apr 2004 11:48:24 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39Fll7X028058; Fri, 9 Apr 2004 11:47:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1653165747.20040408171556@psg.com> References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> <1653165747.20040408171556@psg.com> To: Alex Zinin From: Stephen Kent Cc: Steve Bellovin , saag@mit.edu, idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 9 Apr 2004 11:40:58 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex, > > > >Steve, would you mind making a suggestion on how the text could be improved? >E.g., would a separate section in the main body of the document specifying >the requirement for TCP-MD5 support be useful? A reasonable approach would be to have a section of the document that describes the use of this TCP option. It should explain why/when one would use the option in the context of BGP links and what protection it offers. Somewhere there should be a discussion of precautions should be taken re selection and use of keys, but maybe this is more of a BCP matter than a protocol standards matter. > > >I didn't mean to argue whether the terminology is right or wrong, >I'll leave up >to you guys. My point was that we have to use the actual title of the document >when referring to it, even though the title may not accurately describe what's >inside. Anyway, Steve suggested that a clarifying note is put in the docs... actually, one often refers to an RFC by number in the text, and includes the title only in the references section. > > > But, in a more fundamental sense, we have already >> endorsed the inappropriate use of MD5 in routing protocols in terms >> of OSPF, and we're merely continuing the tradition with BGP and LDP >> :-). > >It seems a discussion on why MD5 is inappropriate or insufficient in >routing protocols would be interesting if we take it to RPSEC. > of course the issue is not MD5 per se, but the use of MD5 plus a secret bit string as a message authentication code, instead of HMAC, in any context. Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 12 12:13:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26822 for ; Mon, 12 Apr 2004 12:13: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 1BD430-0006eq-83 for idr-archive@odin.ietf.org; Mon, 12 Apr 2004 12:12:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CGCYE4025588 for idr-archive@odin.ietf.org; Mon, 12 Apr 2004 12:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD42z-0006ed-4h for idr-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 12:12: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 MAA26811 for ; Mon, 12 Apr 2004 12:12:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD42x-0004uS-00 for idr-web-archive@ietf.org; Mon, 12 Apr 2004 12:12:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD41Y-0004g4-00 for idr-web-archive@ietf.org; Mon, 12 Apr 2004 12:11:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD3zu-0004WR-00; Mon, 12 Apr 2004 12:09:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3za-0006MP-H3; Mon, 12 Apr 2004 12:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByHe-0006mN-UB for idr@optimus.ietf.org; Fri, 09 Apr 2004 11:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03555 for ; Fri, 9 Apr 2004 11:51:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByHd-0001gu-00 for idr@ietf.org; Fri, 09 Apr 2004 11:51:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByGB-0001ZP-00 for idr@ietf.org; Fri, 09 Apr 2004 11:49:40 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BByEy-0001Mk-00 for idr@ietf.org; Fri, 09 Apr 2004 11:48:24 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39Fll7X028058; Fri, 9 Apr 2004 11:47:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1653165747.20040408171556@psg.com> References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> <1653165747.20040408171556@psg.com> To: Alex Zinin From: Stephen Kent Cc: Steve Bellovin , saag@mit.edu, idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 9 Apr 2004 11:40:58 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex, > > > >Steve, would you mind making a suggestion on how the text could be improved? >E.g., would a separate section in the main body of the document specifying >the requirement for TCP-MD5 support be useful? A reasonable approach would be to have a section of the document that describes the use of this TCP option. It should explain why/when one would use the option in the context of BGP links and what protection it offers. Somewhere there should be a discussion of precautions should be taken re selection and use of keys, but maybe this is more of a BCP matter than a protocol standards matter. > > >I didn't mean to argue whether the terminology is right or wrong, >I'll leave up >to you guys. My point was that we have to use the actual title of the document >when referring to it, even though the title may not accurately describe what's >inside. Anyway, Steve suggested that a clarifying note is put in the docs... actually, one often refers to an RFC by number in the text, and includes the title only in the references section. > > > But, in a more fundamental sense, we have already >> endorsed the inappropriate use of MD5 in routing protocols in terms >> of OSPF, and we're merely continuing the tradition with BGP and LDP >> :-). > >It seems a discussion on why MD5 is inappropriate or insufficient in >routing protocols would be interesting if we take it to RPSEC. > of course the issue is not MD5 per se, but the use of MD5 plus a secret bit string as a message authentication code, instead of HMAC, in any context. Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 12:30:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04294 for ; Wed, 14 Apr 2004 12:30:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnHM-0004td-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 12:30:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnGQ-0004nY-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 12:29:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnFi-0004iq-00; Wed, 14 Apr 2004 12:28:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBG-0004uO-3C; Wed, 14 Apr 2004 12:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm3Y-0000ed-8A for idr@optimus.ietf.org; Wed, 14 Apr 2004 11:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00287 for ; Wed, 14 Apr 2004 11:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDm3X-00016x-00 for idr@ietf.org; Wed, 14 Apr 2004 11:12:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDm2d-00013H-00 for idr@ietf.org; Wed, 14 Apr 2004 11:11:08 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BDm1v-0000y6-00 for idr@ietf.org; Wed, 14 Apr 2004 11:10:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3EF9qBm044247; Wed, 14 Apr 2004 08:09:52 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EF9qJ35243; Wed, 14 Apr 2004 08:09:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404141509.i3EF9qJ35243@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88301.1081955392.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document 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, 14 Apr 2004 08:09:52 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, We receive a request to accept draft-lange-flexible-bgp-communities-02.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 28, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 13:18:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07711 for ; Wed, 14 Apr 2004 13:18:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnrO-00073J-39 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 13:07:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EH7ci0027103 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 13:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnHQ-0006LP-72 for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04322 for ; Wed, 14 Apr 2004 12:30:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnHO-0004to-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 12:30:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnGR-0004nn-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 12:29:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnFi-0004iq-00; Wed, 14 Apr 2004 12:28:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBG-0004uO-3C; Wed, 14 Apr 2004 12:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm3Y-0000ed-8A for idr@optimus.ietf.org; Wed, 14 Apr 2004 11:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00287 for ; Wed, 14 Apr 2004 11:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDm3X-00016x-00 for idr@ietf.org; Wed, 14 Apr 2004 11:12:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDm2d-00013H-00 for idr@ietf.org; Wed, 14 Apr 2004 11:11:08 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BDm1v-0000y6-00 for idr@ietf.org; Wed, 14 Apr 2004 11:10:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3EF9qBm044247; Wed, 14 Apr 2004 08:09:52 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EF9qJ35243; Wed, 14 Apr 2004 08:09:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404141509.i3EF9qJ35243@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88301.1081955392.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document 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, 14 Apr 2004 08:09:52 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, We receive a request to accept draft-lange-flexible-bgp-communities-02.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 28, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 16:45:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24153 for ; Wed, 14 Apr 2004 16:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrGF-0001ib-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 16:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrDX-0001GH-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 16:42:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDrCA-00012l-02; Wed, 14 Apr 2004 16:41:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDr5m-00088w-Qa; Wed, 14 Apr 2004 16:34:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqGB-00035Y-Px; Wed, 14 Apr 2004 15:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq8w-0003sC-VM for idr@optimus.ietf.org; Wed, 14 Apr 2004 15:33:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18366; Wed, 14 Apr 2004 15:33:52 -0400 (EDT) Message-Id: <200404141933.PAA18366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2796bis-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, 14 Apr 2004 15:33:52 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Reflection - An Alternative to Full Mesh IBGP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 17:19:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27457 for ; Wed, 14 Apr 2004 17:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDren-0001N5-Bo for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:10:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELArbm005271 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrGI-0001sK-Lu for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 16:45: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 QAA24181 for ; Wed, 14 Apr 2004 16:45:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrGG-0001jB-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 16:45:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrDa-0001Gd-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 16:42:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDrCA-00012l-02; Wed, 14 Apr 2004 16:41:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDr5m-00088w-Qa; Wed, 14 Apr 2004 16:34:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqGB-00035Y-Px; Wed, 14 Apr 2004 15:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq8w-0003sC-VM for idr@optimus.ietf.org; Wed, 14 Apr 2004 15:33:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18366; Wed, 14 Apr 2004 15:33:52 -0400 (EDT) Message-Id: <200404141933.PAA18366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2796bis-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, 14 Apr 2004 15:33:52 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Reflection - An Alternative to Full Mesh IBGP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 17:22:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28027 for ; Wed, 14 Apr 2004 17:22:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrpm-0005lB-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:22:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDroC-0005UA-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:20:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDrln-00058s-00; Wed, 14 Apr 2004 17:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDreH-0000pW-2V; Wed, 14 Apr 2004 17:10:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqu6-0003PV-BP for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:22:38 -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 QAA22150 for ; Wed, 14 Apr 2004 16:22:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDqu4-0006rU-00 for idr@ietf.org; Wed, 14 Apr 2004 16:22:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDqt5-0006ks-00 for idr@ietf.org; Wed, 14 Apr 2004 16:21:36 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDqsC-0006e8-00 for idr@ietf.org; Wed, 14 Apr 2004 16:20:40 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EKK8l80756; Wed, 14 Apr 2004 13:20:08 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKK3J85908; Wed, 14 Apr 2004 13:20:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142020.i3EKK3J85908@merlot.juniper.net> To: Alex Zinin cc: Stephen Kent , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 02 Apr 2004 19:03:02 PST." <14514817.20040402190302@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39377.1081974003.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 13:20:03 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex, > Thanks for looking at this. My comments inline below. > > I've added the IDR mailing list, since your comments cover the base spec as > well. > > Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: > > Steve, > > > The text explaining why the MD5 checksum is not a good candidate for > > use in broader IETF protocol contexts is very well written. > > > The discussion of why BGP-4 can't easily change at this time to > > another integrity mechanism is also very good. However, when I looked > > quickly at the new BGP draft (intended to replace the extant RFC) I > > was unable to find any discussion of using the MD5 option. There are > > references to RFC 2385 in the discussion of what has changed, and in > > the security considerations section, and the normative references > > section. But a search on "MD5," "RFC 2385," "authentication," > > "integrity," or "security" does not point a reader to any text that > > says in any detail how to use this TCP option in the BGP context. > > As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP > Sessions via the TCP MD5 Signature Option", in turn, describes how the option > can be used to secure a TCP sessions, for BGP in particular. Is there somethi ng > specific you were looking for? > > > The > > section entitled "TCP Options that may be used with BGP" makes no > > reference to it. Can someone point me to where the new BGP document > > actually says how this TCP option is used? > > Appendix E "TCP options that may be used with BGP" could indeed mention that > the MD5 option can be used for BGP sessions. Yakov, please log this. Sure. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 17:22:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28172 for ; Wed, 14 Apr 2004 17:22:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrqT-0005rz-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:22:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrpc-0005jl-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:22:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDro3-0005Re-00; Wed, 14 Apr 2004 17:20:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrfg-0002Cq-Qz; Wed, 14 Apr 2004 17:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDr9b-00007t-EU for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:38:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23567 for ; Wed, 14 Apr 2004 16:38:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDr9Z-0000kz-00 for idr@ietf.org; Wed, 14 Apr 2004 16:38:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDr8c-0000eY-00 for idr@ietf.org; Wed, 14 Apr 2004 16:37:38 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDr7k-0000Wc-00 for idr@ietf.org; Wed, 14 Apr 2004 16:36:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EKaEl80825 for ; Wed, 14 Apr 2004 13:36:14 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKa9J87859 for ; Wed, 14 Apr 2004 13:36:09 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142036.i3EKa9J87859@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42084.1081974969.1@juniper.net> From: Yakov Rekhter Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-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, 14 Apr 2004 13:36:09 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 17:24:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28274 for ; Wed, 14 Apr 2004 17:24:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrs2-0005zf-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrr3-0005um-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:23:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDrq3-0005ne-00; Wed, 14 Apr 2004 17:22:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrfq-0002Ny-7k; Wed, 14 Apr 2004 17:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrBa-0000uK-A2 for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23758 for ; Wed, 14 Apr 2004 16:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrBY-0000yS-00 for idr@ietf.org; Wed, 14 Apr 2004 16:40:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrAe-0000sv-00 for idr@ietf.org; Wed, 14 Apr 2004 16:39:44 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BDr9q-0000jP-00 for idr@ietf.org; Wed, 14 Apr 2004 16:38:54 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3EKcHBm050895; Wed, 14 Apr 2004 13:38:17 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKcHJ88016; Wed, 14 Apr 2004 13:38:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142038.i3EKcHJ88016@merlot.juniper.net> To: Stephen Kent cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 09 Apr 2004 11:40:58 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42356.1081975097.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 13:38:17 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Steve, > > > > > > > >Steve, would you mind making a suggestion on how the text could be improved? > >E.g., would a separate section in the main body of the document specifying > >the requirement for TCP-MD5 support be useful? > > A reasonable approach would be to have a section of the document that > describes the use of this TCP option. It should explain why/when one > would use the option in the context of BGP links and what protection > it offers. Would you please produce the appropriate text for this section. Thanks in advance. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 17:39:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29113 for ; Wed, 14 Apr 2004 17:39:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDs6t-0006wV-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:39:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDs5n-0006pG-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 17:38:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDs4u-0006lK-00; Wed, 14 Apr 2004 17:37:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrls-0005lb-S2; Wed, 14 Apr 2004 17:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrbp-0007v3-83 for idr@optimus.ietf.org; Wed, 14 Apr 2004 17:07: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 RAA26171 for ; Wed, 14 Apr 2004 17:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDraZ-0003oF-00 for idr@ietf.org; Wed, 14 Apr 2004 17:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrZa-0003kU-00 for idr@ietf.org; Wed, 14 Apr 2004 17:05:31 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDrYd-0003fe-00 for idr@ietf.org; Wed, 14 Apr 2004 17:04:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EL3tl80928; Wed, 14 Apr 2004 14:03:55 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EL3oJ91061; Wed, 14 Apr 2004 14:03:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142103.i3EL3oJ91061@merlot.juniper.net> To: Steve Bellovin cc: idr@ietf.org, Stephen Kent , Alex Zinin Subject: Re: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Thu, 08 Apr 2004 16:52:18 PDT." <5810329073.20040408165218@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46766.1081976630.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 14:03:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Steve, > This is a forwarded message > From: Steven M. Bellovin > To: Stephen Kent > Cc: Alex Zinin , saag@mit.edu > Date: Wednesday, April 7, 2004, 8:13:10 AM > Subject: [saag] draft-iesg-tcpmd5app-00.txt > > ===8<==============Original message text=============== > In message , Stephen Kent writes: > > >If you look at Steve's document, he uses the right terminology > >throughout, while referring to the document via its RFC number. > >That's a good model for any document that wants to avoid perpetuating > >the terminology error inherent in the title of 2385. > > > > It's probably worth putting a note in my document noting the erroneous > terminology in the title of 2385. It's not a bad idea having a similar > parenthetical note in the bgp document. Could you send me the note, so that I'll include it in the bgp doc. Thanks in advance. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 17:41:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29293 for ; Wed, 14 Apr 2004 17:41:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDs5c-00042V-LG for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:38:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELcabA015522 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrpp-00076D-Ss for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 17:22:17 -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 RAA28052 for ; Wed, 14 Apr 2004 17:22:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrpn-0005lL-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDroG-0005Ui-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:20:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDrln-00058s-00; Wed, 14 Apr 2004 17:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDreH-0000pW-2V; Wed, 14 Apr 2004 17:10:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqu6-0003PV-BP for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:22:38 -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 QAA22150 for ; Wed, 14 Apr 2004 16:22:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDqu4-0006rU-00 for idr@ietf.org; Wed, 14 Apr 2004 16:22:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDqt5-0006ks-00 for idr@ietf.org; Wed, 14 Apr 2004 16:21:36 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDqsC-0006e8-00 for idr@ietf.org; Wed, 14 Apr 2004 16:20:40 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EKK8l80756; Wed, 14 Apr 2004 13:20:08 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKK3J85908; Wed, 14 Apr 2004 13:20:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142020.i3EKK3J85908@merlot.juniper.net> To: Alex Zinin cc: Stephen Kent , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 02 Apr 2004 19:03:02 PST." <14514817.20040402190302@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39377.1081974003.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 13:20:03 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex, > Thanks for looking at this. My comments inline below. > > I've added the IDR mailing list, since your comments cover the base spec as > well. > > Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: > > Steve, > > > The text explaining why the MD5 checksum is not a good candidate for > > use in broader IETF protocol contexts is very well written. > > > The discussion of why BGP-4 can't easily change at this time to > > another integrity mechanism is also very good. However, when I looked > > quickly at the new BGP draft (intended to replace the extant RFC) I > > was unable to find any discussion of using the MD5 option. There are > > references to RFC 2385 in the discussion of what has changed, and in > > the security considerations section, and the normative references > > section. But a search on "MD5," "RFC 2385," "authentication," > > "integrity," or "security" does not point a reader to any text that > > says in any detail how to use this TCP option in the BGP context. > > As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP > Sessions via the TCP MD5 Signature Option", in turn, describes how the option > can be used to secure a TCP sessions, for BGP in particular. Is there somethi ng > specific you were looking for? > > > The > > section entitled "TCP Options that may be used with BGP" makes no > > reference to it. Can someone point me to where the new BGP document > > actually says how this TCP option is used? > > Appendix E "TCP options that may be used with BGP" could indeed mention that > the MD5 option can be used for BGP sessions. Yakov, please log this. Sure. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 17:41:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29389 for ; Wed, 14 Apr 2004 17:41: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 1BDs5e-00045g-UJ for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:38:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELcckh015716 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:38:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrqX-0007NI-US for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 17:23: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 RAA28202 for ; Wed, 14 Apr 2004 17:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrqV-0005sE-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:22:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrpg-0005kN-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:22:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDro3-0005Re-00; Wed, 14 Apr 2004 17:20:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrfg-0002Cq-Qz; Wed, 14 Apr 2004 17:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDr9b-00007t-EU for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:38:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23567 for ; Wed, 14 Apr 2004 16:38:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDr9Z-0000kz-00 for idr@ietf.org; Wed, 14 Apr 2004 16:38:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDr8c-0000eY-00 for idr@ietf.org; Wed, 14 Apr 2004 16:37:38 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDr7k-0000Wc-00 for idr@ietf.org; Wed, 14 Apr 2004 16:36:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EKaEl80825 for ; Wed, 14 Apr 2004 13:36:14 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKa9J87859 for ; Wed, 14 Apr 2004 13:36:09 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142036.i3EKa9J87859@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42084.1081974969.1@juniper.net> From: Yakov Rekhter Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-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, 14 Apr 2004 13:36:09 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 17:42:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29447 for ; Wed, 14 Apr 2004 17:42: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 1BDs5f-00046z-N7 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:38:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELcdLx015801 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrs5-0007w8-P1 for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 17:24:37 -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 RAA28300 for ; Wed, 14 Apr 2004 17:24:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrs3-0005zq-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:24:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrr5-0005v0-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:23:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDrq3-0005ne-00; Wed, 14 Apr 2004 17:22:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrfq-0002Ny-7k; Wed, 14 Apr 2004 17:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrBa-0000uK-A2 for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23758 for ; Wed, 14 Apr 2004 16:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrBY-0000yS-00 for idr@ietf.org; Wed, 14 Apr 2004 16:40:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrAe-0000sv-00 for idr@ietf.org; Wed, 14 Apr 2004 16:39:44 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BDr9q-0000jP-00 for idr@ietf.org; Wed, 14 Apr 2004 16:38:54 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3EKcHBm050895; Wed, 14 Apr 2004 13:38:17 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKcHJ88016; Wed, 14 Apr 2004 13:38:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142038.i3EKcHJ88016@merlot.juniper.net> To: Stephen Kent cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 09 Apr 2004 11:40:58 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42356.1081975097.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 13:38:17 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Steve, > > > > > > > >Steve, would you mind making a suggestion on how the text could be improved? > >E.g., would a separate section in the main body of the document specifying > >the requirement for TCP-MD5 support be useful? > > A reasonable approach would be to have a section of the document that > describes the use of this TCP option. It should explain why/when one > would use the option in the context of BGP links and what protection > it offers. Would you please produce the appropriate text for this section. Thanks in advance. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 17:50:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29975 for ; Wed, 14 Apr 2004 17:50:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsEV-0007uO-Lg for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:47:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELllIb030396 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 17:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDs6z-0004yN-S8 for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 17:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29142 for ; Wed, 14 Apr 2004 17:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDs6x-0006xA-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:39:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDs5o-0006pW-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 17:38:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDs4u-0006lK-00; Wed, 14 Apr 2004 17:37:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrls-0005lb-S2; Wed, 14 Apr 2004 17:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrbp-0007v3-83 for idr@optimus.ietf.org; Wed, 14 Apr 2004 17:07: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 RAA26171 for ; Wed, 14 Apr 2004 17:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDraZ-0003oF-00 for idr@ietf.org; Wed, 14 Apr 2004 17:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrZa-0003kU-00 for idr@ietf.org; Wed, 14 Apr 2004 17:05:31 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDrYd-0003fe-00 for idr@ietf.org; Wed, 14 Apr 2004 17:04:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EL3tl80928; Wed, 14 Apr 2004 14:03:55 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EL3oJ91061; Wed, 14 Apr 2004 14:03:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142103.i3EL3oJ91061@merlot.juniper.net> To: Steve Bellovin cc: idr@ietf.org, Stephen Kent , Alex Zinin Subject: Re: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Thu, 08 Apr 2004 16:52:18 PDT." <5810329073.20040408165218@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46766.1081976630.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 14:03:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Steve, > This is a forwarded message > From: Steven M. Bellovin > To: Stephen Kent > Cc: Alex Zinin , saag@mit.edu > Date: Wednesday, April 7, 2004, 8:13:10 AM > Subject: [saag] draft-iesg-tcpmd5app-00.txt > > ===8<==============Original message text=============== > In message , Stephen Kent writes: > > >If you look at Steve's document, he uses the right terminology > >throughout, while referring to the document via its RFC number. > >That's a good model for any document that wants to avoid perpetuating > >the terminology error inherent in the title of 2385. > > > > It's probably worth putting a note in my document noting the erroneous > terminology in the title of 2385. It's not a bad idea having a similar > parenthetical note in the bgp document. Could you send me the note, so that I'll include it in the bgp doc. Thanks in advance. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 18:16:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02348 for ; Wed, 14 Apr 2004 18:16:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsgc-0001hq-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 18:16:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsfe-0001ey-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 18:15:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDsf1-0001bk-00; Wed, 14 Apr 2004 18:15:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsbz-000207-7b; Wed, 14 Apr 2004 18:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsXl-0008FK-Sd for idr@optimus.ietf.org; Wed, 14 Apr 2004 18:07:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01104 for ; Wed, 14 Apr 2004 18:07:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsXi-000192-00 for idr@ietf.org; Wed, 14 Apr 2004 18:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsX0-00015P-00 for idr@ietf.org; Wed, 14 Apr 2004 18:06:54 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BDsWP-00011e-00 for idr@ietf.org; Wed, 14 Apr 2004 18:06:17 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C3242912AF0; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19736-08; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 9F1C4912AEE; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 7F40115D3C2; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) To: idr@ietf.org Cc: enke@redback.com From: Enke Chen Message-Id: <20040414220616.7F40115D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] I-D ACTION:draft-chen-bgp-cease-subcode-survey-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, 14 Apr 2004 15:06:16 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 FYI. -- Enke ------- Forwarded Message To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-cease-subcode-survey-00.txt Date: Wed, 14 Apr 2004 15:32:43 -0400 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Cease Subcode - Implementation Report Author(s) : E. Chen Filename : draft-chen-bgp-cease-subcode-survey-00.txt Pages : 4 Date : 2004-4-14 This document provides an implementation report for the BGP Cease Subcodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-cease-subcode-survey-00.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 18:26:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02915 for ; Wed, 14 Apr 2004 18:26: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 1BDsmS-0006uQ-F9 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 18:22:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EMMqpY026554 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 18:22:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsgg-0004dq-Od for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 18:16:54 -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 SAA02374 for ; Wed, 14 Apr 2004 18:16:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsgd-0001i0-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 18:16:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsfg-0001fC-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 18:15:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDsf1-0001bk-00; Wed, 14 Apr 2004 18:15:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsbz-000207-7b; Wed, 14 Apr 2004 18:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsXl-0008FK-Sd for idr@optimus.ietf.org; Wed, 14 Apr 2004 18:07:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01104 for ; Wed, 14 Apr 2004 18:07:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsXi-000192-00 for idr@ietf.org; Wed, 14 Apr 2004 18:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsX0-00015P-00 for idr@ietf.org; Wed, 14 Apr 2004 18:06:54 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BDsWP-00011e-00 for idr@ietf.org; Wed, 14 Apr 2004 18:06:17 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C3242912AF0; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19736-08; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 9F1C4912AEE; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 7F40115D3C2; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) To: idr@ietf.org Cc: enke@redback.com From: Enke Chen Message-Id: <20040414220616.7F40115D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] I-D ACTION:draft-chen-bgp-cease-subcode-survey-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, 14 Apr 2004 15:06:16 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 FYI. -- Enke ------- Forwarded Message To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-cease-subcode-survey-00.txt Date: Wed, 14 Apr 2004 15:32:43 -0400 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Cease Subcode - Implementation Report Author(s) : E. Chen Filename : draft-chen-bgp-cease-subcode-survey-00.txt Pages : 4 Date : 2004-4-14 This document provides an implementation report for the BGP Cease Subcodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-cease-subcode-survey-00.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 18:26:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02953 for ; Wed, 14 Apr 2004 18:26:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsq2-0002Ha-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 18:26:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsp4-0002CC-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 18:25:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDso6-00029V-00; Wed, 14 Apr 2004 18:24:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDshk-000563-Oc; Wed, 14 Apr 2004 18:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsdj-0002yY-6q for idr@optimus.ietf.org; Wed, 14 Apr 2004 18:13: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 SAA01894 for ; Wed, 14 Apr 2004 18:13:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsdg-0001W1-00 for idr@ietf.org; Wed, 14 Apr 2004 18:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDscn-0001SY-00 for idr@ietf.org; Wed, 14 Apr 2004 18:12:53 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BDsc7-0001OU-00 for idr@ietf.org; Wed, 14 Apr 2004 18:12:11 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 08BC5912AE7; Wed, 14 Apr 2004 15:12:12 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20510-08; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 97210912AE4; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 47B6615D3C2; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) To: idr@ietf.org Cc: enke@redback.com, yakov@juniper.net, skh@nexthop.com From: Enke Chen Message-Id: <20040414221211.47B6615D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] Implementation survey for BGP Route Reflection 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, 14 Apr 2004 15:12:11 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, folks: We need an implementation report to advance the BGP Route Reflection draft (draft-ietf-idr-rfc2796bis-00.txt). For folks who have done the implementation, could you fill out the simple survey (attached), and send to me by April 28, 2004? Thanks. -- Enke ------------------------------------------------------------------ Implementation Report for BGP Route Reflection (draft-ietf-idr-rfc2796bis-00.txt) Organization: Person filling out this form: Does your implementation follow the procedures specified in the Operation Section when advertising an IBGP learned route to an IBGP peer? Does your implementation recognize the two new attributes (ORIGINATOR_ID and CLUSTER_LIST) defined in the document? Does your implementation perform routing information loop detection based on the ORIGINATOR_ID and the CLUSTER_LIST attributes as specified in the document? Does your implementation format the two new attributes (ORIGINATOR_ID and CLUSTER_LIST) as specified in the document when doing route reflection? Does your implementation take the ORIGNATOR_ID and the CLUSTER_LIST attributes into account in route selection as specified in the document? List other implementations that you have tested for BGP Route Reflection interoperability. ---------------------------------------------------------------------------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 18:35:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03349 for ; Wed, 14 Apr 2004 18:35: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 1BDsvF-0000wL-Jx for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 18:31:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EMVvn9003598 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 18:31:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsq9-0008BA-A3 for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 18:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02992 for ; Wed, 14 Apr 2004 18:26:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsq6-0002I9-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 18:26:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsp6-0002CV-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 18:25:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDso6-00029V-00; Wed, 14 Apr 2004 18:24:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDshk-000563-Oc; Wed, 14 Apr 2004 18:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsdj-0002yY-6q for idr@optimus.ietf.org; Wed, 14 Apr 2004 18:13: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 SAA01894 for ; Wed, 14 Apr 2004 18:13:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsdg-0001W1-00 for idr@ietf.org; Wed, 14 Apr 2004 18:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDscn-0001SY-00 for idr@ietf.org; Wed, 14 Apr 2004 18:12:53 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BDsc7-0001OU-00 for idr@ietf.org; Wed, 14 Apr 2004 18:12:11 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 08BC5912AE7; Wed, 14 Apr 2004 15:12:12 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20510-08; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 97210912AE4; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 47B6615D3C2; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) To: idr@ietf.org Cc: enke@redback.com, yakov@juniper.net, skh@nexthop.com From: Enke Chen Message-Id: <20040414221211.47B6615D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] Implementation survey for BGP Route Reflection 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, 14 Apr 2004 15:12:11 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, folks: We need an implementation report to advance the BGP Route Reflection draft (draft-ietf-idr-rfc2796bis-00.txt). For folks who have done the implementation, could you fill out the simple survey (attached), and send to me by April 28, 2004? Thanks. -- Enke ------------------------------------------------------------------ Implementation Report for BGP Route Reflection (draft-ietf-idr-rfc2796bis-00.txt) Organization: Person filling out this form: Does your implementation follow the procedures specified in the Operation Section when advertising an IBGP learned route to an IBGP peer? Does your implementation recognize the two new attributes (ORIGINATOR_ID and CLUSTER_LIST) defined in the document? Does your implementation perform routing information loop detection based on the ORIGINATOR_ID and the CLUSTER_LIST attributes as specified in the document? Does your implementation format the two new attributes (ORIGINATOR_ID and CLUSTER_LIST) as specified in the document when doing route reflection? Does your implementation take the ORIGNATOR_ID and the CLUSTER_LIST attributes into account in route selection as specified in the document? List other implementations that you have tested for BGP Route Reflection interoperability. ---------------------------------------------------------------------------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 22:33:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12093 for ; Wed, 14 Apr 2004 22:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwhC-0000VP-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 22:33:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwgD-0000S8-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 22:32:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDwfH-0000Pa-00; Wed, 14 Apr 2004 22:31:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwbh-0007os-9i; Wed, 14 Apr 2004 22: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 1BDwYb-0006yl-Nc for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:24: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 WAA11925 for ; Wed, 14 Apr 2004 22:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwYY-00006s-00 for idr@ietf.org; Wed, 14 Apr 2004 22:24:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwXd-00004U-00 for idr@ietf.org; Wed, 14 Apr 2004 22:23:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDwXA-000020-00 for idr@ietf.org; Wed, 14 Apr 2004 22:23:20 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDwXA-000Gc2-76 for idr@ietf.org; Thu, 15 Apr 2004 02:23:20 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <513361939.20040414192319@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 19:23:19 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- I have some technical comments regarding periods of stability and instability in the Internet, BGP steady state, and the security considerations, plus several editorial remarks. See inline below, please. > 2.1. Key Features ... > One of the most important path attributes is the Autonomous System > Path, or AS_PATH. AS reachability information traverses the ^^ "As" > Internet, this information is augmented by the list of autonomous > systems that have been traversed thus far, forming the AS_PATH. The > AS_PATH allows straightforward suppression of the looping of routing > information. In addition, the AS_PATH serves as a powerful and > versatile mechanism for policy-based routing. > > BGP enhances the AS_PATH attribute to include sets of autonomous > systems as well as lists via the AS_SET attribute. This extended > format allows generated aggregate routes to carry path information > from the more specific routes used to generate the aggregate. It > should be noted however, that as of this writing, AS_SETs are rarely > used in the Internet [ROUTEVIEWS]. > > > > 2.2. BGP Algorithms > > > BGP uses an algorithm that is neither a pure distance vector > algorithm or a pure link state algorithm. It is instead a modified > distance vector algorithm referred to as a "Path Vector" algorithm > that uses path information to avoid traditional distance vector > problems. Each route within BGP pairs destination with path > information to that destination. Path information (also known as > AS_PATH information) is stored within the AS_PATH attribute in BGP. > This allows BGP to reconstruct large portions of overall topology > whenever required. I've always been uncomfortable with documents saying that BGP reconstructs the overall topology. It doesn't really do this like the link-state protocols do, for example. > BGP uses an incremental update strategy in order to conserve > bandwidth and processing power. That is, after initial exchange of > complete routing information, a pair of BGP routers exchanges only > changes to that information. Such an incremental update design > requires reliable transport between a pair of BGP routers to function > correctly. BGP solves this problem by using TCP for reliable > transport. Should also note that use of TCP as the transport mechanism helps control congestion and CPU utilization. > > In addition to incremental updates, BGP has added the concept of > route aggregation so that information about groups of networks may be > > > > Meyer and Patel Section 2.2. [Page 5] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > aggregated and sent as a single Network Layer Reachability (NLRI). this doesn't read well. Neither "reachability" nor "information" are countable. "Single prefix" instead? > Finally, note that BGP is a self-contained protocol. That is, BGP > specifies how routing information is exchanged both between BGP > speakers in different autonomous systems, and between BGP speakers > within a single autonomous system. > > > > 2.3. BGP Finite State Machine (FSM) > > > The BGP FSM is a set of rules that are applied to a BGP speaker's set > of configured peers for the BGP operation. A BGP implementation > requires that a BGP speaker must connect to and listen on TCP port > 179 for accepting any new BGP connections from its peers. The BGP > Finite State Machine, or FSM, must be initiated and maintained for > each new incoming and outgoing peer connections. However, in steady > state operation, there will be only one BGP FSM per connection per > peer. > > There may exist a temporary period where in a BGP peer may have > separate incoming and outgoing connections resulting into two > different BGP FSMs for a peer (instead of one). This can be resolved > following BGP connection collision rules defined in the [BGP4]. > > Following are different states of BGP FSM for its peers: > > IDLE: State when BGP peer refuses any incoming > connections. > > CONNECT: State in which BGP peer is waiting for > its TCP connection to be completed. > > ACTIVE: State in which BGP peer is trying to acquire a > peer by listening and accepting TCP connection. > > OPENSENT: BGP peer is waiting for OPEN message from its > peer. > > OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION > message from its peer. > > ESTABLISHED: BGP peer connection is established and exchanges > UPDATE, NOTIFICATION, and KEEPALIVE messages with > its peer. > > There are different BGP events that operate on above mentioned states > > > > Meyer and Patel Section 2.3. [Page 6] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > of BGP FSM for its peers. These BGP events are used for initiating and > terminating peer connections. They also assist BGP in identifying any > persistent peer connection oscillations and provide a mechanism > for controlling them. > > Following are different BGP events: > > Manual Start: Manually start the peer connection. > > Manual Stop: Manually stop the peer connection. > > Automatic Start: Local system automatically starts the peer > connection. > > Manual start with > passive TCP flag: Local system administrator manually starts the > peer connection with peer in passive mode. > > Automatic start > with passive TCP flag: Local system administrator automatically starts > the peer connection with peer in passive mode. > > Automatic start > with bgp_stop_flap > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled. > > Automatic start with > bgp_stop_flap option > set and passive TCP > establishment > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled and with peer in passive mode. > > Automatic stop: Local system automatically stops the > BGP connection. > > Both, Manual Start and Manual Stop are mandatory BGP events. All > other events are optional. > Ummmm... the above are "administrative" events only. There are other events in the FSM, and most of other events are mandatory. > > > > > > > > > Meyer and Patel Section 2.3. [Page 7] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > 3. BGP Capabilities > > > The BGP Capability mechanism [RFC2842] provides an easy and flexible > way to introduce new features within the protocol. In particular, > the BGP capability mechanism allows peers to negotiate various > optional features during startup. This allows the base BGP protocol > to contain only essential functionality, while at the same time > providing a flexible mechanism for signaling protocol extensions. > > > > 4. BGP Persistent Peer Oscillations > > > Ideally, whenever a BGP speaker detects an error in any peer > connection, it shuts down the peer and changes its FSM state to IDLE. > BGP speaker requires a Start event to re-initiate its idle peer > connection. If the error remains persistent and BGP speaker > generates Start event automatically then it may result in persistent > peer flapping. However, although peer oscillation is found to be > wide-spread in BGP implementations, methods for preventing persistent > peer oscillations are outside the scope of base BGP protocol > specification. > > > > 5. Implementation Guidelines > > > A robust BGP implementation is work conserving. This means that if > the number of prefixes is bound, arbitrarily high levels of route > change can be tolerated with bounded impact on route convergence for > occasionally changes in generally stable routes. "occasional"? > > A BGP implementation under high load conditions should empty as much > inbound routing updates from its input streams, processing only the > most recent route if the route for a given NLRI changes multiple > times. TCP also provides blocking on the writes on the sender side. > A BGP implementation under load should expect blocks on write calls > and send only the most recent routes when sockets unblock rather than > sending entire history. > > A robust implementation of BGP should have the following > characteristics: > 1. It is able to operate in almost arbitrarily high levels > of route flap without loosing peerings (failing to send > keepalives) or loosing other protocol adjacencies as a > > > > Meyer and Patel Section 5. [Page 8] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > result of BGP load. > > 2. Instability of a subset of routes should not affect the > route advertisements or forwarding associated with the set > of stable routes. > > 3. High levels of instability and peers of different CPU speed > or load resulting in faster or slower processing of routes > should not cause instability and should have a bounded > impact on the convergence time for generally stable routes. > > Numerous robust BGP implementations exist. Producing a robust > implementation is not a trivial matter but clearly achievable. > > > > > 6. BGP Performance characteristics and Scalability > > > In this section, we provide "order of magnitude" answers to the > questions of how much link bandwidth, router memory and router CPU > cycles the BGP protocol will consume under normal conditions. In > particular, we will address the scalability of BGP and its > limitations. > > > > 6.1. Link bandwidth and CPU utilization > > > Immediately after the initial BGP connection setup, BGP peers > exchange complete set of routing information. If we denote the total > number of routes in the Internet by N, the mean AS distance of the > Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths by A, and assume that the networks are > uniformly distributed among the autonomous systems, then the worst > case amount of bandwidth consumed during the initial exchange between > a pair of BGP speakers is > > BW = O(N + (M * A)) > > The following table illustrates the typical amount of bandwidth > consumed during the initial exchange between a pair of BGP speakers > based on the above assumptions (ignoring bandwidth consumed by the > BGP Header). For purposes of the estimates here, we will calculate > BW = 4 * (N + (M * A)). > > > > Meyer and Patel Section 6.1. [Page 9] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > # NLRI Mean AS Distance # AS's Bandwidth (MR) > ---------- ---------------- ------ ---------------- > 40,000 15 400 184,000 bytes > 100,000 10 10,000 800,000 bytes > 120,000 10 15,000 1,080,000 bytes > 140,000 15 20,000 1,760,000 bytes > > [note that most of this bandwidth is consumed by the NLRI exchange] Is the caption for column 3 correct? It says "# AS's", which reads as "number of AS's" while it seems it should be the number of unique paths. > > BGP was created specifically to reduce the size of the set of NLRI > entries which have to be carried and exchanged by border routers. > The aggregation scheme, defined in RFC 1519 [RFC1519], describes the > provider-based aggregation scheme in use in today's Internet. > > Due to the advantages of advertising a few large aggregate blocks > instead of many smaller class-based individual networks, it is > difficult to estimate the actual reduction in bandwidth and > processing that BGP has provided over BGP-3. If we simply enumerate > all aggregate blocks into their individual class-based networks, we > would not take into account "dead" space that has been reserved for > future expansion. The best metric for determining the success of > BGP's aggregation is to sample the number NLRI entries in the > globally connected Internet today and compare it to projected growth > rates before BGP was deployed. > > At the time of this writing, the full set of exterior routes carried > by BGP is approximately 120,000 network entries [ROUTEVIEWS]. > > > > 6.1.1. CPU utilization > > > An important and fundamental feature of BGP is that BGP's CPU > utilization depends only on the stability of the Internet. If the > Internet is stable, then the only link bandwidth and router CPU > cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE > messages. The KEEPALIVE messages are exchanged only between peers. > The suggested frequency of the exchange is 30 seconds. The KEEPALIVE > messages are quite short (19 octets), and require virtually no > processing. As a result, the bandwidth consumed by the KEEPALIVE > messages is about 5 bits/sec. Operational experience confirms that > the overhead (in terms of bandwidth and CPU) associated with the > KEEPALIVE messages should be viewed as negligible. > > During periods of Internet instability, changes to the reachability > information are passed between routers in UPDATE messages. The While theoretically the text is correct and we could talk about periods of stability and instability of the Internet, I wonder if this text is still applicable from the practical perspective. I.e., the continuous churn that the Internet BGP speakers experience ensures that they practically always have something to process. Probably instead of talking about periods of "Internet stability" and "Internet instability" we could talk about something like "periods of stable state among BGP speakers when they do no have new updates to communicate to each other". > > Meyer and Patel Section 6.1.1. [Page 10] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > greatest overhead per UPDATE message occurs when each UPDATE message > contains only a single network. It should be pointed out that in > practice routing changes exhibit strong locality with respect to the > AS path. That is, routes that change are likely to have common AS > path. In this case, multiple networks can be grouped into a single > UPDATE message, thus significantly reducing the amount of bandwidth > required (see also Appendix F.1 of [BGP4]). > > Since in the steady state the link bandwidth and router CPU cycles > consumed by the BGP protocol are dependent only on the stability of > the Internet, it follows that BGP should have no scaling problems in > the areas of link bandwidth and router CPU utilization. Not sure I follow here. What is meant by the "steady state" here? If it means convergence on a stable topology after the initial exchange of updates, then why talk about "stability of the Internet"? In other words, if the Internet is unstable then can we say that the BGP speakers are in steady state? In the lack of topology changes, it seems that the consumption should instead depend on the number of peers (affects KEEPALIVE processing) and the number of persistently oscillating routes potentially present in the network... > This assumes > that as the Internet grows, the overall stability of the inter-AS > connectivity of the Internet can be controlled. please specify how it is assumed to be "controlled", e.g. through operational practices. > In particular, while > the size of the IPv4 Internet routing table is bounded by O(232 * M), 232 or 2^32? > (where M is a slow-moving function describing the AS > interconnectivity of the network), slow-moving or slow-growing? > no such bound can be formulated > for the dynamic properties (i.e., stability) of BGP. Although, the > dynamic properties of the network cannot be quantitatively bounded, > they can be controlled within BGP. Beyond certain changes in the > network, BGP can start to suppress such changes using BGP Route Flap > Damping [RFC2439], pacing of its route updates, or BGP would be > unable to keep up with the changes and force suppression of multiple > changes over very short periods by causing the BGP peer socket to > block on the sender. > > > > 6.1.2. Memory requirements > > > To quantify the worst case memory requirements for BGP, we denote the > total number of networks in the Internet by N, the mean AS distance > of the Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths as A. Then the worst case memory > requirements (MR) can be expressed as > > > MR = O(N + (M * A)) > > > Since a mean AS distance M is a slow moving function of the > interconnectivity ("meshiness") of the Internet, for all practical > purposes the worst case router memory requirements are on the order > of the total number of networks in the Internet times the number of > peers the local system is peering with. We expect that the total > number of networks in the Internet will grow much faster than the > > > > Meyer and Patel Section 6.1.2. [Page 11] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > average number of peers per router. As a result, BGP's memory > scaling properties are linearly related to the total number of > networks in the Internet. > > The following table illustrates typical memory requirements of a > router running BGP. We denote average number of routes advertised by > each peer as N, the total number of unique AS paths as A, the mean AS > distance of the Internet as M (distance at the level of an autonomous > system, expressed in terms of the number of autonomous systems), > number of bytes required to store a route as R, and number of bytes > required to store one AS in an AS path as P. It is assumed that each > network is encoded as four bytes, each AS is encoded as two bytes, > and each networks is reachable via some fraction of all of the peers > (# BGP peers/per net). For purposes of the estimates here, we will > calculate MR = ((N * R) + (M * A) * P) > > > # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) > ---------- ---------------- ------ ------------------- -------------- > 100,000 20 3,000 20 1,040,000 > 100,000 20 15,000 20 1,040,000 > 120,000 10 15,000 100 75,000,000 > 140,000 15 20,000 100 116,000,000 > > > In analyzing BGP's memory requirements, we focus on the size of the > forwarding table (and ignoring implementation details). In > particular, we derive upper bounds for the size of the forwarding > table. The above doesn't look like calculations for a forwarding table--the FIB doesn't normally contact AS-PATH info or all possible paths to a destination. > > 11. Security Considerations > > > This document presents an analysis of the BGP protocol and as such > presents no new security implications for BGP. I'm afraid the IESG will expect to see some more here. Specifically, I would suggest that the document talks about available security mechanisms, and the analysis of how they affect processing overhead, BW, and scalability. Certainly a pointer to the bgp-vuln document would be useful. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 22:37:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12276 for ; Wed, 14 Apr 2004 22:37: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 1BDwj2-0001Eb-Cb for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 22:35:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F2ZaSG004740 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 22:35:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwhH-0000e9-66 for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 22:33:47 -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 WAA12118 for ; Wed, 14 Apr 2004 22:33:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwhD-0000VZ-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 22:33:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwgH-0000SN-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 22:32:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDwfH-0000Pa-00; Wed, 14 Apr 2004 22:31:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwbh-0007os-9i; Wed, 14 Apr 2004 22: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 1BDwYb-0006yl-Nc for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:24: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 WAA11925 for ; Wed, 14 Apr 2004 22:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwYY-00006s-00 for idr@ietf.org; Wed, 14 Apr 2004 22:24:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwXd-00004U-00 for idr@ietf.org; Wed, 14 Apr 2004 22:23:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDwXA-000020-00 for idr@ietf.org; Wed, 14 Apr 2004 22:23:20 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDwXA-000Gc2-76 for idr@ietf.org; Thu, 15 Apr 2004 02:23:20 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <513361939.20040414192319@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 19:23:19 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- I have some technical comments regarding periods of stability and instability in the Internet, BGP steady state, and the security considerations, plus several editorial remarks. See inline below, please. > 2.1. Key Features ... > One of the most important path attributes is the Autonomous System > Path, or AS_PATH. AS reachability information traverses the ^^ "As" > Internet, this information is augmented by the list of autonomous > systems that have been traversed thus far, forming the AS_PATH. The > AS_PATH allows straightforward suppression of the looping of routing > information. In addition, the AS_PATH serves as a powerful and > versatile mechanism for policy-based routing. > > BGP enhances the AS_PATH attribute to include sets of autonomous > systems as well as lists via the AS_SET attribute. This extended > format allows generated aggregate routes to carry path information > from the more specific routes used to generate the aggregate. It > should be noted however, that as of this writing, AS_SETs are rarely > used in the Internet [ROUTEVIEWS]. > > > > 2.2. BGP Algorithms > > > BGP uses an algorithm that is neither a pure distance vector > algorithm or a pure link state algorithm. It is instead a modified > distance vector algorithm referred to as a "Path Vector" algorithm > that uses path information to avoid traditional distance vector > problems. Each route within BGP pairs destination with path > information to that destination. Path information (also known as > AS_PATH information) is stored within the AS_PATH attribute in BGP. > This allows BGP to reconstruct large portions of overall topology > whenever required. I've always been uncomfortable with documents saying that BGP reconstructs the overall topology. It doesn't really do this like the link-state protocols do, for example. > BGP uses an incremental update strategy in order to conserve > bandwidth and processing power. That is, after initial exchange of > complete routing information, a pair of BGP routers exchanges only > changes to that information. Such an incremental update design > requires reliable transport between a pair of BGP routers to function > correctly. BGP solves this problem by using TCP for reliable > transport. Should also note that use of TCP as the transport mechanism helps control congestion and CPU utilization. > > In addition to incremental updates, BGP has added the concept of > route aggregation so that information about groups of networks may be > > > > Meyer and Patel Section 2.2. [Page 5] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > aggregated and sent as a single Network Layer Reachability (NLRI). this doesn't read well. Neither "reachability" nor "information" are countable. "Single prefix" instead? > Finally, note that BGP is a self-contained protocol. That is, BGP > specifies how routing information is exchanged both between BGP > speakers in different autonomous systems, and between BGP speakers > within a single autonomous system. > > > > 2.3. BGP Finite State Machine (FSM) > > > The BGP FSM is a set of rules that are applied to a BGP speaker's set > of configured peers for the BGP operation. A BGP implementation > requires that a BGP speaker must connect to and listen on TCP port > 179 for accepting any new BGP connections from its peers. The BGP > Finite State Machine, or FSM, must be initiated and maintained for > each new incoming and outgoing peer connections. However, in steady > state operation, there will be only one BGP FSM per connection per > peer. > > There may exist a temporary period where in a BGP peer may have > separate incoming and outgoing connections resulting into two > different BGP FSMs for a peer (instead of one). This can be resolved > following BGP connection collision rules defined in the [BGP4]. > > Following are different states of BGP FSM for its peers: > > IDLE: State when BGP peer refuses any incoming > connections. > > CONNECT: State in which BGP peer is waiting for > its TCP connection to be completed. > > ACTIVE: State in which BGP peer is trying to acquire a > peer by listening and accepting TCP connection. > > OPENSENT: BGP peer is waiting for OPEN message from its > peer. > > OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION > message from its peer. > > ESTABLISHED: BGP peer connection is established and exchanges > UPDATE, NOTIFICATION, and KEEPALIVE messages with > its peer. > > There are different BGP events that operate on above mentioned states > > > > Meyer and Patel Section 2.3. [Page 6] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > of BGP FSM for its peers. These BGP events are used for initiating and > terminating peer connections. They also assist BGP in identifying any > persistent peer connection oscillations and provide a mechanism > for controlling them. > > Following are different BGP events: > > Manual Start: Manually start the peer connection. > > Manual Stop: Manually stop the peer connection. > > Automatic Start: Local system automatically starts the peer > connection. > > Manual start with > passive TCP flag: Local system administrator manually starts the > peer connection with peer in passive mode. > > Automatic start > with passive TCP flag: Local system administrator automatically starts > the peer connection with peer in passive mode. > > Automatic start > with bgp_stop_flap > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled. > > Automatic start with > bgp_stop_flap option > set and passive TCP > establishment > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled and with peer in passive mode. > > Automatic stop: Local system automatically stops the > BGP connection. > > Both, Manual Start and Manual Stop are mandatory BGP events. All > other events are optional. > Ummmm... the above are "administrative" events only. There are other events in the FSM, and most of other events are mandatory. > > > > > > > > > Meyer and Patel Section 2.3. [Page 7] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > 3. BGP Capabilities > > > The BGP Capability mechanism [RFC2842] provides an easy and flexible > way to introduce new features within the protocol. In particular, > the BGP capability mechanism allows peers to negotiate various > optional features during startup. This allows the base BGP protocol > to contain only essential functionality, while at the same time > providing a flexible mechanism for signaling protocol extensions. > > > > 4. BGP Persistent Peer Oscillations > > > Ideally, whenever a BGP speaker detects an error in any peer > connection, it shuts down the peer and changes its FSM state to IDLE. > BGP speaker requires a Start event to re-initiate its idle peer > connection. If the error remains persistent and BGP speaker > generates Start event automatically then it may result in persistent > peer flapping. However, although peer oscillation is found to be > wide-spread in BGP implementations, methods for preventing persistent > peer oscillations are outside the scope of base BGP protocol > specification. > > > > 5. Implementation Guidelines > > > A robust BGP implementation is work conserving. This means that if > the number of prefixes is bound, arbitrarily high levels of route > change can be tolerated with bounded impact on route convergence for > occasionally changes in generally stable routes. "occasional"? > > A BGP implementation under high load conditions should empty as much > inbound routing updates from its input streams, processing only the > most recent route if the route for a given NLRI changes multiple > times. TCP also provides blocking on the writes on the sender side. > A BGP implementation under load should expect blocks on write calls > and send only the most recent routes when sockets unblock rather than > sending entire history. > > A robust implementation of BGP should have the following > characteristics: > 1. It is able to operate in almost arbitrarily high levels > of route flap without loosing peerings (failing to send > keepalives) or loosing other protocol adjacencies as a > > > > Meyer and Patel Section 5. [Page 8] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > result of BGP load. > > 2. Instability of a subset of routes should not affect the > route advertisements or forwarding associated with the set > of stable routes. > > 3. High levels of instability and peers of different CPU speed > or load resulting in faster or slower processing of routes > should not cause instability and should have a bounded > impact on the convergence time for generally stable routes. > > Numerous robust BGP implementations exist. Producing a robust > implementation is not a trivial matter but clearly achievable. > > > > > 6. BGP Performance characteristics and Scalability > > > In this section, we provide "order of magnitude" answers to the > questions of how much link bandwidth, router memory and router CPU > cycles the BGP protocol will consume under normal conditions. In > particular, we will address the scalability of BGP and its > limitations. > > > > 6.1. Link bandwidth and CPU utilization > > > Immediately after the initial BGP connection setup, BGP peers > exchange complete set of routing information. If we denote the total > number of routes in the Internet by N, the mean AS distance of the > Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths by A, and assume that the networks are > uniformly distributed among the autonomous systems, then the worst > case amount of bandwidth consumed during the initial exchange between > a pair of BGP speakers is > > BW = O(N + (M * A)) > > The following table illustrates the typical amount of bandwidth > consumed during the initial exchange between a pair of BGP speakers > based on the above assumptions (ignoring bandwidth consumed by the > BGP Header). For purposes of the estimates here, we will calculate > BW = 4 * (N + (M * A)). > > > > Meyer and Patel Section 6.1. [Page 9] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > # NLRI Mean AS Distance # AS's Bandwidth (MR) > ---------- ---------------- ------ ---------------- > 40,000 15 400 184,000 bytes > 100,000 10 10,000 800,000 bytes > 120,000 10 15,000 1,080,000 bytes > 140,000 15 20,000 1,760,000 bytes > > [note that most of this bandwidth is consumed by the NLRI exchange] Is the caption for column 3 correct? It says "# AS's", which reads as "number of AS's" while it seems it should be the number of unique paths. > > BGP was created specifically to reduce the size of the set of NLRI > entries which have to be carried and exchanged by border routers. > The aggregation scheme, defined in RFC 1519 [RFC1519], describes the > provider-based aggregation scheme in use in today's Internet. > > Due to the advantages of advertising a few large aggregate blocks > instead of many smaller class-based individual networks, it is > difficult to estimate the actual reduction in bandwidth and > processing that BGP has provided over BGP-3. If we simply enumerate > all aggregate blocks into their individual class-based networks, we > would not take into account "dead" space that has been reserved for > future expansion. The best metric for determining the success of > BGP's aggregation is to sample the number NLRI entries in the > globally connected Internet today and compare it to projected growth > rates before BGP was deployed. > > At the time of this writing, the full set of exterior routes carried > by BGP is approximately 120,000 network entries [ROUTEVIEWS]. > > > > 6.1.1. CPU utilization > > > An important and fundamental feature of BGP is that BGP's CPU > utilization depends only on the stability of the Internet. If the > Internet is stable, then the only link bandwidth and router CPU > cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE > messages. The KEEPALIVE messages are exchanged only between peers. > The suggested frequency of the exchange is 30 seconds. The KEEPALIVE > messages are quite short (19 octets), and require virtually no > processing. As a result, the bandwidth consumed by the KEEPALIVE > messages is about 5 bits/sec. Operational experience confirms that > the overhead (in terms of bandwidth and CPU) associated with the > KEEPALIVE messages should be viewed as negligible. > > During periods of Internet instability, changes to the reachability > information are passed between routers in UPDATE messages. The While theoretically the text is correct and we could talk about periods of stability and instability of the Internet, I wonder if this text is still applicable from the practical perspective. I.e., the continuous churn that the Internet BGP speakers experience ensures that they practically always have something to process. Probably instead of talking about periods of "Internet stability" and "Internet instability" we could talk about something like "periods of stable state among BGP speakers when they do no have new updates to communicate to each other". > > Meyer and Patel Section 6.1.1. [Page 10] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > greatest overhead per UPDATE message occurs when each UPDATE message > contains only a single network. It should be pointed out that in > practice routing changes exhibit strong locality with respect to the > AS path. That is, routes that change are likely to have common AS > path. In this case, multiple networks can be grouped into a single > UPDATE message, thus significantly reducing the amount of bandwidth > required (see also Appendix F.1 of [BGP4]). > > Since in the steady state the link bandwidth and router CPU cycles > consumed by the BGP protocol are dependent only on the stability of > the Internet, it follows that BGP should have no scaling problems in > the areas of link bandwidth and router CPU utilization. Not sure I follow here. What is meant by the "steady state" here? If it means convergence on a stable topology after the initial exchange of updates, then why talk about "stability of the Internet"? In other words, if the Internet is unstable then can we say that the BGP speakers are in steady state? In the lack of topology changes, it seems that the consumption should instead depend on the number of peers (affects KEEPALIVE processing) and the number of persistently oscillating routes potentially present in the network... > This assumes > that as the Internet grows, the overall stability of the inter-AS > connectivity of the Internet can be controlled. please specify how it is assumed to be "controlled", e.g. through operational practices. > In particular, while > the size of the IPv4 Internet routing table is bounded by O(232 * M), 232 or 2^32? > (where M is a slow-moving function describing the AS > interconnectivity of the network), slow-moving or slow-growing? > no such bound can be formulated > for the dynamic properties (i.e., stability) of BGP. Although, the > dynamic properties of the network cannot be quantitatively bounded, > they can be controlled within BGP. Beyond certain changes in the > network, BGP can start to suppress such changes using BGP Route Flap > Damping [RFC2439], pacing of its route updates, or BGP would be > unable to keep up with the changes and force suppression of multiple > changes over very short periods by causing the BGP peer socket to > block on the sender. > > > > 6.1.2. Memory requirements > > > To quantify the worst case memory requirements for BGP, we denote the > total number of networks in the Internet by N, the mean AS distance > of the Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths as A. Then the worst case memory > requirements (MR) can be expressed as > > > MR = O(N + (M * A)) > > > Since a mean AS distance M is a slow moving function of the > interconnectivity ("meshiness") of the Internet, for all practical > purposes the worst case router memory requirements are on the order > of the total number of networks in the Internet times the number of > peers the local system is peering with. We expect that the total > number of networks in the Internet will grow much faster than the > > > > Meyer and Patel Section 6.1.2. [Page 11] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > average number of peers per router. As a result, BGP's memory > scaling properties are linearly related to the total number of > networks in the Internet. > > The following table illustrates typical memory requirements of a > router running BGP. We denote average number of routes advertised by > each peer as N, the total number of unique AS paths as A, the mean AS > distance of the Internet as M (distance at the level of an autonomous > system, expressed in terms of the number of autonomous systems), > number of bytes required to store a route as R, and number of bytes > required to store one AS in an AS path as P. It is assumed that each > network is encoded as four bytes, each AS is encoded as two bytes, > and each networks is reachable via some fraction of all of the peers > (# BGP peers/per net). For purposes of the estimates here, we will > calculate MR = ((N * R) + (M * A) * P) > > > # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) > ---------- ---------------- ------ ------------------- -------------- > 100,000 20 3,000 20 1,040,000 > 100,000 20 15,000 20 1,040,000 > 120,000 10 15,000 100 75,000,000 > 140,000 15 20,000 100 116,000,000 > > > In analyzing BGP's memory requirements, we focus on the size of the > forwarding table (and ignoring implementation details). In > particular, we derive upper bounds for the size of the forwarding > table. The above doesn't look like calculations for a forwarding table--the FIB doesn't normally contact AS-PATH info or all possible paths to a destination. > > 11. Security Considerations > > > This document presents an analysis of the BGP protocol and as such > presents no new security implications for BGP. I'm afraid the IESG will expect to see some more here. Specifically, I would suggest that the document talks about available security mechanisms, and the analysis of how they affect processing overhead, BW, and scalability. Certainly a pointer to the bgp-vuln document would be useful. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 22:49:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12731 for ; Wed, 14 Apr 2004 22:49:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwwn-0001SD-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 22:49:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwvp-0001OT-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 22:48:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDwuz-0001M5-00; Wed, 14 Apr 2004 22:47:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwt7-0003tA-BI; Wed, 14 Apr 2004 22:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwr0-0003JS-TX for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:43: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 WAA12573 for ; Wed, 14 Apr 2004 22:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwqx-00016u-00 for idr@ietf.org; Wed, 14 Apr 2004 22:43:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwq1-00013U-00 for idr@ietf.org; Wed, 14 Apr 2004 22:42:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDwp6-00010H-00 for idr@ietf.org; Wed, 14 Apr 2004 22:41:52 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDwp6-000LFs-SJ for idr@ietf.org; Thu, 15 Apr 2004 02:41:52 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1778578854.20040414194151@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-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, 14 Apr 2004 19:41:51 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- Several comments inline below. > 1.1 General > > This draft of BGP-4 attempts to bring BGP standard as described in Seems like this is out of context. > RFC 1771 in alignment with the deployments of the BGP-4 protocols. > The changes with RFC 1771 are listed in the appendix A of[BGP4]. > BGP-4 as deployed in the Internet encompasses both this base > specification and additional specifications such as TCP MD5 > [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations > [RFC3065], and BGP Route Refresh [RFC 2918]. > > BGP as a widely deployed cornerstone of Internet technology > continues to add additional functionality as the needs within the > Internet require. This survey had 259 detailed questions on the > compliances with the standard. 3 implementers (Cisco, Laurel, > NextHop) sent in implementation reports. Sections X - Y provides > the compilation of those results. > > X implementers who responded below indicating inter-operability with > other implementations. Of these X implementations, Y also indicated > the length of the survey was as problem. The editor recommends that > other methods, such as enlisting existing testing vendors be > employed to gather more implementation report. > > Section Z provides the quick survey results on inter-operability. > > > > Hares & Retana Expires - August 2004 [Page 3] > > > > > draft-ietf-idr-bgp-implementation-00 February 2004 > > X, Y, and Z need to be filled out... ;) > 1.2 Full Survey result summary > > Significant Differences > > All 259 survey points had two "y" or "y" and "O" except the > following: At this point of the document, it is not clear what "y" and "0" are. > Generally, if we don't have at least two implementations for a specific feature, it can't stay in the spec. The granularity of the BGP implementation report is finer than on a per-feature basis, but we still need to see if the spec needs to be fixed accordingly. More specific comments below: > MUST - Question 214 > > Question 214 about aggregation of routes. section 9.1.4 had a "N" > response from 3 implementers indicating that they install both > routes, and 1 yes. when I look at section 2.43.214, I see: Alcatel Y/N/O/Comments: Y Cisco Y/N/O/Comments: Y Laurel Y/N/O/Comments: Y NextHop Y/N/O/Comments: Y wrong section? > SHALL NOT - Question 228, regarding section 9.2.2.2 > > Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall not > (meaning they did). One vendor (NextHop) indicate "y" matching > the specification. > > text: Routes that have different MULTI_EXIT_DISC attribute SHALL > NOT be aggregated. If this is considered to be important for protocol correctness, then the WG may consider softening the requirements language and changing it to "SHOULD NOT"--apparently some implementers found that under certain circumstances such routes still need to be aggregated. > SHOULD - 2 in appendix F (questions 257, 258) > > Three vendors said no, one vendor said yes to question 257. All > four vendors indicated no to question 258. (Please note that > Appendix F is an optional text section) > > Text: section F.2 - A BGP speaker which needs to withdraw a > destination and send an update about a more specific or less > specific route SHOULD combine them into the same UPDATE message. > > Text: Section F.6: The last instance (rightmost occurrence) of > that AS number is kept. Assuming that the appendices are not a normative part of the spec, the 2119 language should not be used there. ... > 1.4 Implementations and interoperability > > Short informal summary of implementers reporting implementations and > inter-operability > > [This section will be added later but will have the format below ] > > Alcatel Cisco Laurel NextHop > Alcatel > Cisco > Laurel > NextHop the above table needs to be filled out. > 1.5 BGP Implementation Identification This section does not specify the origin of code > 1.5.0 Alcatel > > 1.5.1 Cisco > Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S > Date: 11/26/2003 > > 1.5.2 Laurel > > 1.5.3 NextHop Technologies > Implementation Name/Version: Gated NGC 2.0, 2.2 > Date: January 2004 > > > Hares & Retana Expires - August 2004 [Page 5] > > > > > draft-ietf-idr-bgp-implementation-00 February 2004 > > > > 2. BGP4 Implementation Report > > For every item listed, the respondents indicated whether their > implementation supports the Functionality/Description or not (Y/N) > according to the RFC2119 [3] language indicated. "according to the RFC 2119" should probably be removed. The implementation either decides to support something the 2119 language prescribes in some form or it doesn't. > Any respondent > comments are included. If appropriate, the respondents indicated > with O the fact that the support is neither Y/N (an alternate > behavior, for example). Refer to the appropriate sections in the > latest BGP-4 ID [4] for additional details. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 22:57:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12931 for ; Wed, 14 Apr 2004 22:57: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 1BDwzU-0005Ra-Ck for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 22:52:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F2qan1020922 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 22:52:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwwr-0004sK-U2 for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 22:49: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 WAA12757 for ; Wed, 14 Apr 2004 22:49:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwwo-0001SN-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 22:49:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwvr-0001Oh-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 22:48:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDwuz-0001M5-00; Wed, 14 Apr 2004 22:47:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwt7-0003tA-BI; Wed, 14 Apr 2004 22:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwr0-0003JS-TX for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:43: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 WAA12573 for ; Wed, 14 Apr 2004 22:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwqx-00016u-00 for idr@ietf.org; Wed, 14 Apr 2004 22:43:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwq1-00013U-00 for idr@ietf.org; Wed, 14 Apr 2004 22:42:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDwp6-00010H-00 for idr@ietf.org; Wed, 14 Apr 2004 22:41:52 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDwp6-000LFs-SJ for idr@ietf.org; Thu, 15 Apr 2004 02:41:52 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1778578854.20040414194151@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-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, 14 Apr 2004 19:41:51 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Several comments inline below. > 1.1 General > > This draft of BGP-4 attempts to bring BGP standard as described in Seems like this is out of context. > RFC 1771 in alignment with the deployments of the BGP-4 protocols. > The changes with RFC 1771 are listed in the appendix A of[BGP4]. > BGP-4 as deployed in the Internet encompasses both this base > specification and additional specifications such as TCP MD5 > [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations > [RFC3065], and BGP Route Refresh [RFC 2918]. > > BGP as a widely deployed cornerstone of Internet technology > continues to add additional functionality as the needs within the > Internet require. This survey had 259 detailed questions on the > compliances with the standard. 3 implementers (Cisco, Laurel, > NextHop) sent in implementation reports. Sections X - Y provides > the compilation of those results. > > X implementers who responded below indicating inter-operability with > other implementations. Of these X implementations, Y also indicated > the length of the survey was as problem. The editor recommends that > other methods, such as enlisting existing testing vendors be > employed to gather more implementation report. > > Section Z provides the quick survey results on inter-operability. > > > > Hares & Retana Expires - August 2004 [Page 3] > > > > > draft-ietf-idr-bgp-implementation-00 February 2004 > > X, Y, and Z need to be filled out... ;) > 1.2 Full Survey result summary > > Significant Differences > > All 259 survey points had two "y" or "y" and "O" except the > following: At this point of the document, it is not clear what "y" and "0" are. > Generally, if we don't have at least two implementations for a specific feature, it can't stay in the spec. The granularity of the BGP implementation report is finer than on a per-feature basis, but we still need to see if the spec needs to be fixed accordingly. More specific comments below: > MUST - Question 214 > > Question 214 about aggregation of routes. section 9.1.4 had a "N" > response from 3 implementers indicating that they install both > routes, and 1 yes. when I look at section 2.43.214, I see: Alcatel Y/N/O/Comments: Y Cisco Y/N/O/Comments: Y Laurel Y/N/O/Comments: Y NextHop Y/N/O/Comments: Y wrong section? > SHALL NOT - Question 228, regarding section 9.2.2.2 > > Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall not > (meaning they did). One vendor (NextHop) indicate "y" matching > the specification. > > text: Routes that have different MULTI_EXIT_DISC attribute SHALL > NOT be aggregated. If this is considered to be important for protocol correctness, then the WG may consider softening the requirements language and changing it to "SHOULD NOT"--apparently some implementers found that under certain circumstances such routes still need to be aggregated. > SHOULD - 2 in appendix F (questions 257, 258) > > Three vendors said no, one vendor said yes to question 257. All > four vendors indicated no to question 258. (Please note that > Appendix F is an optional text section) > > Text: section F.2 - A BGP speaker which needs to withdraw a > destination and send an update about a more specific or less > specific route SHOULD combine them into the same UPDATE message. > > Text: Section F.6: The last instance (rightmost occurrence) of > that AS number is kept. Assuming that the appendices are not a normative part of the spec, the 2119 language should not be used there. ... > 1.4 Implementations and interoperability > > Short informal summary of implementers reporting implementations and > inter-operability > > [This section will be added later but will have the format below ] > > Alcatel Cisco Laurel NextHop > Alcatel > Cisco > Laurel > NextHop the above table needs to be filled out. > 1.5 BGP Implementation Identification This section does not specify the origin of code > 1.5.0 Alcatel > > 1.5.1 Cisco > Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S > Date: 11/26/2003 > > 1.5.2 Laurel > > 1.5.3 NextHop Technologies > Implementation Name/Version: Gated NGC 2.0, 2.2 > Date: January 2004 > > > Hares & Retana Expires - August 2004 [Page 5] > > > > > draft-ietf-idr-bgp-implementation-00 February 2004 > > > > 2. BGP4 Implementation Report > > For every item listed, the respondents indicated whether their > implementation supports the Functionality/Description or not (Y/N) > according to the RFC2119 [3] language indicated. "according to the RFC 2119" should probably be removed. The implementation either decides to support something the 2119 language prescribes in some form or it doesn't. > Any respondent > comments are included. If appropriate, the respondents indicated > with O the fact that the support is neither Y/N (an alternate > behavior, for example). Refer to the appropriate sections in the > latest BGP-4 ID [4] for additional details. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 14 23:07:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13342 for ; Wed, 14 Apr 2004 23:07:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDxEI-0002Ve-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 23:07:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDxCN-0002OH-00 for idr-archive@ietf.org; Wed, 14 Apr 2004 23:05:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDxAo-0002Hm-00; Wed, 14 Apr 2004 23:04:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx5h-0006qU-OP; Wed, 14 Apr 2004 22: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 1BDx3l-0006AV-2O for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:57: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 WAA12926 for ; Wed, 14 Apr 2004 22:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx3h-0001pp-00 for idr@ietf.org; Wed, 14 Apr 2004 22:56:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDx3I-0001mG-00 for idr@ietf.org; Wed, 14 Apr 2004 22:56:32 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDx2D-0001jb-00 for idr@ietf.org; Wed, 14 Apr 2004 22:55:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDx2E-000O3x-6T for idr@ietf.org; Thu, 15 Apr 2004 02:55:26 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <953258565.20040414195525@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp4-experience-protocol-03.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 19:55:25 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- I'm generally quite happy with this document. The only comment I had was about the way the 2119 requirements language is used. In some places (simple search for "MUST" would reveal), the document reads as defining protocol procedures, which should be in the protocol spec. If the intention is to quote the spec, the wording should be changed accordingly. Refs to SBGP and SoBGP should be filled in. Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 14 23:18:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13710 for ; Wed, 14 Apr 2004 23:18: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 1BDxNF-00039y-Qm for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 23:17:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F3H9FC012136 for idr-archive@odin.ietf.org; Wed, 14 Apr 2004 23:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxEU-0001II-F3 for idr-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 23:08: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 XAA13368 for ; Wed, 14 Apr 2004 23:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDxEP-0002Vz-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 23:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDxCS-0002Oj-00 for idr-web-archive@ietf.org; Wed, 14 Apr 2004 23:06:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDxAo-0002Hm-00; Wed, 14 Apr 2004 23:04:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx5h-0006qU-OP; Wed, 14 Apr 2004 22: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 1BDx3l-0006AV-2O for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:57: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 WAA12926 for ; Wed, 14 Apr 2004 22:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx3h-0001pp-00 for idr@ietf.org; Wed, 14 Apr 2004 22:56:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDx3I-0001mG-00 for idr@ietf.org; Wed, 14 Apr 2004 22:56:32 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDx2D-0001jb-00 for idr@ietf.org; Wed, 14 Apr 2004 22:55:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDx2E-000O3x-6T for idr@ietf.org; Thu, 15 Apr 2004 02:55:26 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <953258565.20040414195525@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp4-experience-protocol-03.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 19:55:25 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- I'm generally quite happy with this document. The only comment I had was about the way the 2119 requirements language is used. In some places (simple search for "MUST" would reveal), the document reads as defining protocol procedures, which should be in the protocol spec. If the intention is to quote the spec, the wording should be changed accordingly. Refs to SBGP and SoBGP should be filled in. Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 09:56:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24193 for ; Thu, 15 Apr 2004 09:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Le-0004dZ-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 09:56:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7Kg-0004ZI-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 09:55:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7K7-0004Vh-00; Thu, 15 Apr 2004 09:54:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Dn-0002c5-Lb; Thu, 15 Apr 2004 09:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE783-0000Dh-B3 for idr@optimus.ietf.org; Thu, 15 Apr 2004 09:42:07 -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 JAA23443 for ; Thu, 15 Apr 2004 09:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE781-0003Gy-00 for idr@ietf.org; Thu, 15 Apr 2004 09:42:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE772-0003Be-00 for idr@ietf.org; Thu, 15 Apr 2004 09:41:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BE763-00033K-00 for idr@ietf.org; Thu, 15 Apr 2004 09:40:03 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EBC532D4848 for ; Thu, 15 Apr 2004 09:39:32 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13783-01-25 for ; Thu, 15 Apr 2004 09:39:20 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 066EA2D4834 for ; Thu, 15 Apr 2004 09:39:20 -0400 (EDT) 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: draft-chavali-bgp-prefixlimit-01.txt Thread-Index: AcQi7w3l0C/aXkMNTJaWNIxQs7XfjQ== From: "Susan Hares" To: Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] draft-chavali-bgp-prefixlimit-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: Thu, 15 Apr 2004 09:39:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I would like to request this this draft becoming a working group draft. Discussion during IETF 58, indicated there was interest from service providers to having this become a working group draft. Sue ---------- Title : Peer Prefix Limits Exchange in BGP Author(s) : V. Radoaca, et al. Filename : draft-chavali-bgp-prefixlimit-01.txt Pages : 14 Date : 2004-4-12 Abstract: This document proposes a mechanism to allow BGP peers to=20 coordinate the setting of a lmit on the number of prefix=20 which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding=20 of routes, which can occur when a maximum prefix limit is=20 configured on the "receiving" peer, and the "sending" peer exceeds the limit. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 10:08:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25137 for ; Thu, 15 Apr 2004 10:08: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 1BE7LP-0004xU-I3 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 09:55:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDttsH019052 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 09:55:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7F8-000327-MU for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:49:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23838 for ; Thu, 15 Apr 2004 09:49:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7F6-00041i-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 09:49:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7E8-0003vb-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 09:48:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7DW-0003ph-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 09:47:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE77H-0008Lg-1p for idr-web-archive@ietf.org; Thu, 15 Apr 2004 09:41:19 -0400 Date: Thu, 15 Apr 2004 09:41:19 -0400 Message-ID: <20040415134119.32059.33452.Mailman@www1.ietf.org> Subject: Idr@ietf.org mailing list reminder From: idr-request@ietf.org To: idr-web-archive@ietf.org X-No-Archive: yes X-Ack: no 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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ************************************************************************** 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. ************************************************************************** This is a reminder of how to unsubscribe or change your configuration for the address "idr-web-archive@ietf.org" on the mailing list Idr. You need to have your password for these things. YOUR Idr PASSWORD IS: ginaip To make changes to your subscription, use the password on your options World Wide Web page: https://www1.ietf.org/mailman/options/idr/idr-web-archive%40ietf.org You can also make such changes via email - send a message to: idr-request@ietf.org with the text "help" in the subject or body, and you will be emailed instructions. Questions or comments? Please send them to idr-admin@ietf.org. From idr-admin@ietf.org Thu Apr 15 10:15:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26024 for ; Thu, 15 Apr 2004 10:15:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7eJ-0006Ne-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 10:15:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7dO-0006HB-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 10:14:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7ct-0006BF-00; Thu, 15 Apr 2004 10:13:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7MU-0005HW-MP; Thu, 15 Apr 2004 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Fw-0003dR-V5 for idr@optimus.ietf.org; Thu, 15 Apr 2004 09:50:17 -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 JAA23910 for ; Thu, 15 Apr 2004 09:50:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Fv-00048I-00 for idr@ietf.org; Thu, 15 Apr 2004 09:50:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7FH-00043S-00 for idr@ietf.org; Thu, 15 Apr 2004 09:49:36 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Eh-0003wG-00; Thu, 15 Apr 2004 09:48:59 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3FDmRl84173; Thu, 15 Apr 2004 06:48:27 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3FDmMJ91101; Thu, 15 Apr 2004 06:48:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404151348.i3FDmMJ91101@merlot.juniper.net> To: zinin@psg.com, fenner@research.att.com cc: idr@ietf.org, iesg-secretary@ietf.org, skh@nexthop.com, yakov@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89571.1082036871.1@juniper.net> From: Yakov Rekhter Subject: [Idr] BGP Cease subcodes to Proposed Standard 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, 15 Apr 2004 06:48:22 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex and Bill, The IDR WG would like to ask the IESG to advance BGP Cease Subcodes (draft-ietf-idr-cease-subcode-04.txt) to a Proposed Standard. The implementation report is in draft-chen-bgp-cease-subcode-survey-00.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 10:17:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26389 for ; Thu, 15 Apr 2004 10:17:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7cT-0007Up-Ny for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:13:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEDXie028811 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:13:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Lh-0005DQ-Lg for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24216 for ; Thu, 15 Apr 2004 09:56:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Lf-0004dj-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 09:56:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7Kh-0004ZW-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 09:55:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7K7-0004Vh-00; Thu, 15 Apr 2004 09:54:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Dn-0002c5-Lb; Thu, 15 Apr 2004 09:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE783-0000Dh-B3 for idr@optimus.ietf.org; Thu, 15 Apr 2004 09:42:07 -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 JAA23443 for ; Thu, 15 Apr 2004 09:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE781-0003Gy-00 for idr@ietf.org; Thu, 15 Apr 2004 09:42:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE772-0003Be-00 for idr@ietf.org; Thu, 15 Apr 2004 09:41:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BE763-00033K-00 for idr@ietf.org; Thu, 15 Apr 2004 09:40:03 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EBC532D4848 for ; Thu, 15 Apr 2004 09:39:32 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13783-01-25 for ; Thu, 15 Apr 2004 09:39:20 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 066EA2D4834 for ; Thu, 15 Apr 2004 09:39:20 -0400 (EDT) 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: draft-chavali-bgp-prefixlimit-01.txt Thread-Index: AcQi7w3l0C/aXkMNTJaWNIxQs7XfjQ== From: "Susan Hares" To: Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] draft-chavali-bgp-prefixlimit-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: Thu, 15 Apr 2004 09:39:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I would like to request this this draft becoming a working group draft. Discussion during IETF 58, indicated there was interest from service providers to having this become a working group draft. Sue ---------- Title : Peer Prefix Limits Exchange in BGP Author(s) : V. Radoaca, et al. Filename : draft-chavali-bgp-prefixlimit-01.txt Pages : 14 Date : 2004-4-12 Abstract: This document proposes a mechanism to allow BGP peers to=20 coordinate the setting of a lmit on the number of prefix=20 which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding=20 of routes, which can occur when a maximum prefix limit is=20 configured on the "receiving" peer, and the "sending" peer exceeds the limit. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 10:21:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26780 for ; Thu, 15 Apr 2004 10:21:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7k7-000736-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 10:21:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7jA-0006wj-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 10:20:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7ih-0006r7-00; Thu, 15 Apr 2004 10:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7dt-0008J7-MJ; Thu, 15 Apr 2004 10:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7RQ-0008RO-8Q for idr@optimus.ietf.org; Thu, 15 Apr 2004 10:02: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 KAA24501 for ; Thu, 15 Apr 2004 10:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7RO-00059Y-00 for idr@ietf.org; Thu, 15 Apr 2004 10:02:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7QT-00055l-00 for idr@ietf.org; Thu, 15 Apr 2004 10:01:10 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Pr-0004xP-00 for idr@ietf.org; Thu, 15 Apr 2004 10:00:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3FDxxl84207 for ; Thu, 15 Apr 2004 06:59:59 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3FDxsJ92103 for ; Thu, 15 Apr 2004 06:59:54 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404151359.i3FDxsJ92103@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92039.1082037594.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document 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, 15 Apr 2004 06:59:54 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 29, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 10:25:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26972 for ; Thu, 15 Apr 2004 10:25:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7nj-0007Mx-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 10:25:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7mt-0007It-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 10:24:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7mF-0007El-00; Thu, 15 Apr 2004 10:23:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7dv-0008Jx-8D; Thu, 15 Apr 2004 10:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7TP-00028y-F7 for idr@optimus.ietf.org; Thu, 15 Apr 2004 10:04: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 KAA24633 for ; Thu, 15 Apr 2004 10:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7TN-0005KN-00 for idr@ietf.org; Thu, 15 Apr 2004 10:04:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7SW-0005Fe-00 for idr@ietf.org; Thu, 15 Apr 2004 10:03:17 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Rd-00056o-00 for idr@ietf.org; Thu, 15 Apr 2004 10:02:21 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3FE1mo04788 for ; Thu, 15 Apr 2004 10:01:48 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29RLKK0M; Thu, 15 Apr 2004 10:01:47 -0400 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JXWC; Thu, 15 Apr 2004 10:01:47 -0400 Message-ID: <407E95C2.3070901@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: multipart/mixed; boundary="------------080105020709010800040801" Subject: [Idr] [Fwd: I-D ACTION:draft-chavali-bgp-prefixlimit-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: Thu, 15 Apr 2004 10:01:38 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------080105020709010800040801 Content-Type: multipart/alternative; boundary="------------020505080408090500090101" --------------020505080408090500090101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI: -------- Original Message -------- Subject: I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt Date: Mon, 12 Apr 2004 15:31:26 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Peer Prefix Limits Exchange in BGP Author(s) : V. Radoaca, et al. Filename : draft-chavali-bgp-prefixlimit-01.txt Pages : 14 Date : 2004-4-12 This document proposes a mechanism to allow BGP peers to coordinate the setting of a limit on the number of prefixes which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding of routes, which can occur when a maximum prefix limit is configured on the 'receiving' peer, and the 'sending' peer exceeds the limit. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-chavali-bgp-prefixlimit-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-chavali-bgp-prefixlimit-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. --------------020505080408090500090101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit FYI:

-------- Original Message --------
Subject: I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt
Date: Mon, 12 Apr 2004 15:31:26 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Peer Prefix Limits Exchange in BGP
	Author(s)	: V. Radoaca, et al.
	Filename	: draft-chavali-bgp-prefixlimit-01.txt
	Pages		: 14
	Date		: 2004-4-12
	
This document proposes a mechanism to allow BGP peers to coordinate
the setting of a limit on the number of prefixes which one BGP
speaker will send to its peer.  Coordination can prevent disruption
of the peering session or discarding of routes, which can occur when
a maximum prefix limit is configured on the 'receiving' peer, and the
'sending' peer exceeds the limit.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-chavali-bgp-prefixlimit-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-chavali-bgp-prefixlimit-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.
--------------020505080408090500090101-- --------------080105020709010800040801 Content-Type: Message/External-body; name="draft-chavali-bgp-prefixlimit-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chavali-bgp-prefixlimit-01.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --------------080105020709010800040801-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 10:34:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27478 for ; Thu, 15 Apr 2004 10:34: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 1BE7oV-0005BE-Dm for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:25:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEPxFH019903 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:25:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7eN-0000Fo-Fg for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:15: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 KAA26049 for ; Thu, 15 Apr 2004 10:15:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7eK-0006Np-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 10:15:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7dP-0006HP-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 10:14:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7ct-0006BF-00; Thu, 15 Apr 2004 10:13:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7MU-0005HW-MP; Thu, 15 Apr 2004 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Fw-0003dR-V5 for idr@optimus.ietf.org; Thu, 15 Apr 2004 09:50:17 -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 JAA23910 for ; Thu, 15 Apr 2004 09:50:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Fv-00048I-00 for idr@ietf.org; Thu, 15 Apr 2004 09:50:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7FH-00043S-00 for idr@ietf.org; Thu, 15 Apr 2004 09:49:36 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Eh-0003wG-00; Thu, 15 Apr 2004 09:48:59 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3FDmRl84173; Thu, 15 Apr 2004 06:48:27 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3FDmMJ91101; Thu, 15 Apr 2004 06:48:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404151348.i3FDmMJ91101@merlot.juniper.net> To: zinin@psg.com, fenner@research.att.com cc: idr@ietf.org, iesg-secretary@ietf.org, skh@nexthop.com, yakov@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89571.1082036871.1@juniper.net> From: Yakov Rekhter Subject: [Idr] BGP Cease subcodes to Proposed Standard 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, 15 Apr 2004 06:48:22 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex and Bill, The IDR WG would like to ask the IESG to advance BGP Cease Subcodes (draft-ietf-idr-cease-subcode-04.txt) to a Proposed Standard. The implementation report is in draft-chen-bgp-cease-subcode-survey-00.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 10:41:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27803 for ; Thu, 15 Apr 2004 10:41:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7vp-0008PY-7s for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:33:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEXXEv032317 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7kB-00037R-6f for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:21: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 KAA26804 for ; Thu, 15 Apr 2004 10:21:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7k8-00073H-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 10:21:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7jC-0006wy-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 10:20:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7ih-0006r7-00; Thu, 15 Apr 2004 10:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7dt-0008J7-MJ; Thu, 15 Apr 2004 10:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7RQ-0008RO-8Q for idr@optimus.ietf.org; Thu, 15 Apr 2004 10:02: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 KAA24501 for ; Thu, 15 Apr 2004 10:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7RO-00059Y-00 for idr@ietf.org; Thu, 15 Apr 2004 10:02:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7QT-00055l-00 for idr@ietf.org; Thu, 15 Apr 2004 10:01:10 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Pr-0004xP-00 for idr@ietf.org; Thu, 15 Apr 2004 10:00:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3FDxxl84207 for ; Thu, 15 Apr 2004 06:59:59 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3FDxsJ92103 for ; Thu, 15 Apr 2004 06:59:54 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404151359.i3FDxsJ92103@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92039.1082037594.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document 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, 15 Apr 2004 06:59:54 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 29, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 10:42:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27857 for ; Thu, 15 Apr 2004 10:42: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 1BE7vy-0008UY-Cn for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:33:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEXgA6032638 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 10:33:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7nm-00052b-In for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:25: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 KAA26984 for ; Thu, 15 Apr 2004 10:25:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7nk-0007N7-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 10:25:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7mw-0007J7-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 10:24:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7mF-0007El-00; Thu, 15 Apr 2004 10:23:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7dv-0008Jx-8D; Thu, 15 Apr 2004 10:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7TP-00028y-F7 for idr@optimus.ietf.org; Thu, 15 Apr 2004 10:04: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 KAA24633 for ; Thu, 15 Apr 2004 10:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7TN-0005KN-00 for idr@ietf.org; Thu, 15 Apr 2004 10:04:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7SW-0005Fe-00 for idr@ietf.org; Thu, 15 Apr 2004 10:03:17 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Rd-00056o-00 for idr@ietf.org; Thu, 15 Apr 2004 10:02:21 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3FE1mo04788 for ; Thu, 15 Apr 2004 10:01:48 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29RLKK0M; Thu, 15 Apr 2004 10:01:47 -0400 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JXWC; Thu, 15 Apr 2004 10:01:47 -0400 Message-ID: <407E95C2.3070901@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: multipart/mixed; boundary="------------080105020709010800040801" Subject: [Idr] [Fwd: I-D ACTION:draft-chavali-bgp-prefixlimit-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: Thu, 15 Apr 2004 10:01:38 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------080105020709010800040801 Content-Type: multipart/alternative; boundary="------------020505080408090500090101" --------------020505080408090500090101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI: -------- Original Message -------- Subject: I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt Date: Mon, 12 Apr 2004 15:31:26 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Peer Prefix Limits Exchange in BGP Author(s) : V. Radoaca, et al. Filename : draft-chavali-bgp-prefixlimit-01.txt Pages : 14 Date : 2004-4-12 This document proposes a mechanism to allow BGP peers to coordinate the setting of a limit on the number of prefixes which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding of routes, which can occur when a maximum prefix limit is configured on the 'receiving' peer, and the 'sending' peer exceeds the limit. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-chavali-bgp-prefixlimit-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-chavali-bgp-prefixlimit-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. --------------020505080408090500090101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit FYI:

-------- Original Message --------
Subject: I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt
Date: Mon, 12 Apr 2004 15:31:26 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Peer Prefix Limits Exchange in BGP
	Author(s)	: V. Radoaca, et al.
	Filename	: draft-chavali-bgp-prefixlimit-01.txt
	Pages		: 14
	Date		: 2004-4-12
	
This document proposes a mechanism to allow BGP peers to coordinate
the setting of a limit on the number of prefixes which one BGP
speaker will send to its peer.  Coordination can prevent disruption
of the peering session or discarding of routes, which can occur when
a maximum prefix limit is configured on the 'receiving' peer, and the
'sending' peer exceeds the limit.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-chavali-bgp-prefixlimit-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-chavali-bgp-prefixlimit-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.
--------------020505080408090500090101-- --------------080105020709010800040801 Content-Type: Message/External-body; name="draft-chavali-bgp-prefixlimit-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chavali-bgp-prefixlimit-01.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --------------080105020709010800040801-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 11:52:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01596 for ; Thu, 15 Apr 2004 11:52:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE99u-0000YA-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 11:52:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE996-0000To-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 11:51:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE98R-0000PC-00; Thu, 15 Apr 2004 11:50:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8xB-0005wZ-81; Thu, 15 Apr 2004 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8pf-0003oF-QG for idr@optimus.ietf.org; Thu, 15 Apr 2004 11:31:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00785 for ; Thu, 15 Apr 2004 11:31:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8pe-0006Sc-00 for idr@ietf.org; Thu, 15 Apr 2004 11:31:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8oj-0006M2-00 for idr@ietf.org; Thu, 15 Apr 2004 11:30:17 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8nv-00068L-00 for idr@ietf.org; Thu, 15 Apr 2004 11:29:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3FFSl016149; Thu, 15 Apr 2004 18:28:47 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: <200404151359.i3FDxsJ92103@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Apr 2004, Yakov Rekhter wrote: > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. The applicability does not seem to be sufficiently clear. That is, people use prefix limits for a *reason*. Once set, they're set until they are changed. There's no urgent need to specify anything here. However, I agree that it might not hurt to have some option that could be used to inform the peer on your limits, so that: - the operator of the peer could notice this when examining the neighbor's info (i.e., when contemplating about advertising new prefixes), or - if the peer exceeded the prefix limits, the peer's operator would notice that a warning/stop threshold has been reached (this could result in an SNMP trap, flashing led, or whatever.) I fail to see a need for anything more than that, and the current document *seems* to be more complex than that. Unless I'm mistaken, I'm not sure if going forward with this draft is a good idea. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 12:27:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02778 for ; Thu, 15 Apr 2004 12:27:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9N2-0004ru-Uw for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 12:05:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FG5ign018708 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 12:05:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE99x-0001zk-1u for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 11:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01620 for ; Thu, 15 Apr 2004 11:52:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE99v-0000YK-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 11:52:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE997-0000U3-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 11:51:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE98R-0000PC-00; Thu, 15 Apr 2004 11:50:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8xB-0005wZ-81; Thu, 15 Apr 2004 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8pf-0003oF-QG for idr@optimus.ietf.org; Thu, 15 Apr 2004 11:31:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00785 for ; Thu, 15 Apr 2004 11:31:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8pe-0006Sc-00 for idr@ietf.org; Thu, 15 Apr 2004 11:31:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8oj-0006M2-00 for idr@ietf.org; Thu, 15 Apr 2004 11:30:17 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8nv-00068L-00 for idr@ietf.org; Thu, 15 Apr 2004 11:29:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3FFSl016149; Thu, 15 Apr 2004 18:28:47 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: <200404151359.i3FDxsJ92103@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Apr 2004, Yakov Rekhter wrote: > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. The applicability does not seem to be sufficiently clear. That is, people use prefix limits for a *reason*. Once set, they're set until they are changed. There's no urgent need to specify anything here. However, I agree that it might not hurt to have some option that could be used to inform the peer on your limits, so that: - the operator of the peer could notice this when examining the neighbor's info (i.e., when contemplating about advertising new prefixes), or - if the peer exceeded the prefix limits, the peer's operator would notice that a warning/stop threshold has been reached (this could result in an SNMP trap, flashing led, or whatever.) I fail to see a need for anything more than that, and the current document *seems* to be more complex than that. Unless I'm mistaken, I'm not sure if going forward with this draft is a good idea. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 12:43:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03709 for ; Thu, 15 Apr 2004 12:43:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9xL-0005Re-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 12:43:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9wQ-0005KU-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 12:42:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9vV-0005DN-00; Thu, 15 Apr 2004 12:41:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9jZ-0005Zt-7p; Thu, 15 Apr 2004 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9QO-0005bX-0u for idr@optimus.ietf.org; Thu, 15 Apr 2004 12: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 ESMTP id MAA02182 for ; Thu, 15 Apr 2004 12:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9QM-00024H-00 for idr@ietf.org; Thu, 15 Apr 2004 12:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9PQ-0001zq-00 for idr@ietf.org; Thu, 15 Apr 2004 12:08:12 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BE9OZ-0001rP-00 for idr@ietf.org; Thu, 15 Apr 2004 12:07:19 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3FG6bB08123; Thu, 15 Apr 2004 12:06:37 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29RLKQ9V; Thu, 15 Apr 2004 12:06:36 -0400 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JX6Z; Thu, 15 Apr 2004 12:06:36 -0400 Message-ID: <407EB30C.5040007@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document References: In-Reply-To: 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: Thu, 15 Apr 2004 12:06:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Pekka , Pekka Savola wrote: >I fail to see a need for anything more than that, and the current >document *seems* to be more complex than that. > >Unless I'm mistaken, I'm not sure if going forward with this draft is > > >a good idea. > The draft addresses the issue described on a per AFI/SAFI pair and hence the need for additional mechanism. The requirement for different limits has come from the SPs which is why that is included. Thats the reason for tailoring the mechanism around it. srikanth chavali _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 12:59:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04556 for ; Thu, 15 Apr 2004 12:59:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEA4X-0003uZ-CN for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGofSu015031 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9xP-00014P-87 for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:43: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 MAA03735 for ; Thu, 15 Apr 2004 12:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9xN-0005Rx-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 12:43:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9wR-0005Km-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 12:42:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9vV-0005DN-00; Thu, 15 Apr 2004 12:41:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9jZ-0005Zt-7p; Thu, 15 Apr 2004 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9QO-0005bX-0u for idr@optimus.ietf.org; Thu, 15 Apr 2004 12: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 ESMTP id MAA02182 for ; Thu, 15 Apr 2004 12:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9QM-00024H-00 for idr@ietf.org; Thu, 15 Apr 2004 12:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9PQ-0001zq-00 for idr@ietf.org; Thu, 15 Apr 2004 12:08:12 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BE9OZ-0001rP-00 for idr@ietf.org; Thu, 15 Apr 2004 12:07:19 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3FG6bB08123; Thu, 15 Apr 2004 12:06:37 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29RLKQ9V; Thu, 15 Apr 2004 12:06:36 -0400 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JX6Z; Thu, 15 Apr 2004 12:06:36 -0400 Message-ID: <407EB30C.5040007@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document References: In-Reply-To: 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: Thu, 15 Apr 2004 12:06:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka , Pekka Savola wrote: >I fail to see a need for anything more than that, and the current >document *seems* to be more complex than that. > >Unless I'm mistaken, I'm not sure if going forward with this draft is > > >a good idea. > The draft addresses the issue described on a per AFI/SAFI pair and hence the need for additional mechanism. The requirement for different limits has come from the SPs which is why that is included. Thats the reason for tailoring the mechanism around it. srikanth chavali _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 13:28:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07267 for ; Thu, 15 Apr 2004 13:28:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAep-0002XO-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 13:28:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAds-0002TJ-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 13:27:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEAd2-0002Oy-00; Thu, 15 Apr 2004 13:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAWx-0002w2-Rr; Thu, 15 Apr 2004 13: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 1BEAMg-0000qG-M4 for idr@optimus.ietf.org; Thu, 15 Apr 2004 13:09:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05369 for ; Thu, 15 Apr 2004 13:09:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAMe-0000lw-00 for idr@ietf.org; Thu, 15 Apr 2004 13:09:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEALf-0000e0-00 for idr@ietf.org; Thu, 15 Apr 2004 13:08:25 -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 1BEAKj-0000Sc-00 for idr@ietf.org; Thu, 15 Apr 2004 13:07:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2004 09:17:27 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3FH6p7t029487; Thu, 15 Apr 2004 10:06:51 -0700 (PDT) Received: from cisco.com (keyupate-lnx.cisco.com [128.107.163.249]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ARI16143; Thu, 15 Apr 2004 10:05:06 -0700 (PDT) Message-ID: <407EC12A.6040109@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: Alex Zinin CC: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt References: <513361939.20040414192319@psg.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: Thu, 15 Apr 2004 10:06:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex: Thanks for the comments. We will incorporate them. -Keyur Alex Zinin wrote: >Folks- > >I have some technical comments regarding periods of stability and instability in >the Internet, BGP steady state, and the security considerations, plus several >editorial remarks. > >See inline below, please. > > > >>2.1. Key Features >> >> >... > > >> One of the most important path attributes is the Autonomous System >> Path, or AS_PATH. AS reachability information traverses the >> >> > ^^ > "As" > > > >> Internet, this information is augmented by the list of autonomous >> systems that have been traversed thus far, forming the AS_PATH. The >> AS_PATH allows straightforward suppression of the looping of routing >> information. In addition, the AS_PATH serves as a powerful and >> versatile mechanism for policy-based routing. >> >> BGP enhances the AS_PATH attribute to include sets of autonomous >> systems as well as lists via the AS_SET attribute. This extended >> format allows generated aggregate routes to carry path information >> from the more specific routes used to generate the aggregate. It >> should be noted however, that as of this writing, AS_SETs are rarely >> used in the Internet [ROUTEVIEWS]. >> >> >> >>2.2. BGP Algorithms >> >> >> BGP uses an algorithm that is neither a pure distance vector >> algorithm or a pure link state algorithm. It is instead a modified >> distance vector algorithm referred to as a "Path Vector" algorithm >> that uses path information to avoid traditional distance vector >> problems. Each route within BGP pairs destination with path >> information to that destination. Path information (also known as >> AS_PATH information) is stored within the AS_PATH attribute in BGP. >> This allows BGP to reconstruct large portions of overall topology >> whenever required. >> >> > >I've always been uncomfortable with documents saying that BGP reconstructs the >overall topology. It doesn't really do this like the link-state protocols do, >for example. > > > >> BGP uses an incremental update strategy in order to conserve >> bandwidth and processing power. That is, after initial exchange of >> complete routing information, a pair of BGP routers exchanges only >> changes to that information. Such an incremental update design >> requires reliable transport between a pair of BGP routers to function >> correctly. BGP solves this problem by using TCP for reliable >> transport. >> >> > >Should also note that use of TCP as the transport mechanism helps control >congestion and CPU utilization. > > > >> In addition to incremental updates, BGP has added the concept of >> route aggregation so that information about groups of networks may be >> >> >> >>Meyer and Patel Section 2.2. [Page 5] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> aggregated and sent as a single Network Layer Reachability (NLRI). >> >> > >this doesn't read well. Neither "reachability" nor "information" are countable. >"Single prefix" instead? > > > >> Finally, note that BGP is a self-contained protocol. That is, BGP >> specifies how routing information is exchanged both between BGP >> speakers in different autonomous systems, and between BGP speakers >> within a single autonomous system. >> >> >> >>2.3. BGP Finite State Machine (FSM) >> >> >> The BGP FSM is a set of rules that are applied to a BGP speaker's set >> of configured peers for the BGP operation. A BGP implementation >> requires that a BGP speaker must connect to and listen on TCP port >> 179 for accepting any new BGP connections from its peers. The BGP >> Finite State Machine, or FSM, must be initiated and maintained for >> each new incoming and outgoing peer connections. However, in steady >> state operation, there will be only one BGP FSM per connection per >> peer. >> >> There may exist a temporary period where in a BGP peer may have >> separate incoming and outgoing connections resulting into two >> different BGP FSMs for a peer (instead of one). This can be resolved >> following BGP connection collision rules defined in the [BGP4]. >> >> Following are different states of BGP FSM for its peers: >> >> IDLE: State when BGP peer refuses any incoming >> connections. >> >> CONNECT: State in which BGP peer is waiting for >> its TCP connection to be completed. >> >> ACTIVE: State in which BGP peer is trying to acquire a >> peer by listening and accepting TCP connection. >> >> OPENSENT: BGP peer is waiting for OPEN message from its >> peer. >> >> OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION >> message from its peer. >> >> ESTABLISHED: BGP peer connection is established and exchanges >> UPDATE, NOTIFICATION, and KEEPALIVE messages with >> its peer. >> >> There are different BGP events that operate on above mentioned states >> >> >> >>Meyer and Patel Section 2.3. [Page 6] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> of BGP FSM for its peers. These BGP events are used for initiating and >> terminating peer connections. They also assist BGP in identifying any >> persistent peer connection oscillations and provide a mechanism >> for controlling them. >> >> Following are different BGP events: >> >> Manual Start: Manually start the peer connection. >> >> Manual Stop: Manually stop the peer connection. >> >> Automatic Start: Local system automatically starts the peer >> connection. >> >> Manual start with >> passive TCP flag: Local system administrator manually starts the >> peer connection with peer in passive mode. >> >> Automatic start >> with passive TCP flag: Local system administrator automatically starts >> the peer connection with peer in passive mode. >> >> Automatic start >> with bgp_stop_flap >> option set: Local system administrator automatically starts >> the peer connection with peer oscillation >> damping enabled. >> >> Automatic start with >> bgp_stop_flap option >> set and passive TCP >> establishment >> option set: Local system administrator automatically starts >> the peer connection with peer oscillation >> damping enabled and with peer in passive mode. >> >> Automatic stop: Local system automatically stops the >> BGP connection. >> >> Both, Manual Start and Manual Stop are mandatory BGP events. All >> other events are optional. >> >> >> > >Ummmm... the above are "administrative" events only. There are other events in >the FSM, and most of other events are mandatory. > > > >> >> >> >> >> >> >>Meyer and Patel Section 2.3. [Page 7] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >>3. BGP Capabilities >> >> >> The BGP Capability mechanism [RFC2842] provides an easy and flexible >> way to introduce new features within the protocol. In particular, >> the BGP capability mechanism allows peers to negotiate various >> optional features during startup. This allows the base BGP protocol >> to contain only essential functionality, while at the same time >> providing a flexible mechanism for signaling protocol extensions. >> >> >> >>4. BGP Persistent Peer Oscillations >> >> >> Ideally, whenever a BGP speaker detects an error in any peer >> connection, it shuts down the peer and changes its FSM state to IDLE. >> BGP speaker requires a Start event to re-initiate its idle peer >> connection. If the error remains persistent and BGP speaker >> generates Start event automatically then it may result in persistent >> peer flapping. However, although peer oscillation is found to be >> wide-spread in BGP implementations, methods for preventing persistent >> peer oscillations are outside the scope of base BGP protocol >> specification. >> >> >> >>5. Implementation Guidelines >> >> >> A robust BGP implementation is work conserving. This means that if >> the number of prefixes is bound, arbitrarily high levels of route >> change can be tolerated with bounded impact on route convergence for >> occasionally changes in generally stable routes. >> >> > >"occasional"? > > > >> A BGP implementation under high load conditions should empty as much >> inbound routing updates from its input streams, processing only the >> most recent route if the route for a given NLRI changes multiple >> times. TCP also provides blocking on the writes on the sender side. >> A BGP implementation under load should expect blocks on write calls >> and send only the most recent routes when sockets unblock rather than >> sending entire history. >> >> A robust implementation of BGP should have the following >> characteristics: >> 1. It is able to operate in almost arbitrarily high levels >> of route flap without loosing peerings (failing to send >> keepalives) or loosing other protocol adjacencies as a >> >> >> >>Meyer and Patel Section 5. [Page 8] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> result of BGP load. >> >> 2. Instability of a subset of routes should not affect the >> route advertisements or forwarding associated with the set >> of stable routes. >> >> 3. High levels of instability and peers of different CPU speed >> or load resulting in faster or slower processing of routes >> should not cause instability and should have a bounded >> impact on the convergence time for generally stable routes. >> >> Numerous robust BGP implementations exist. Producing a robust >> implementation is not a trivial matter but clearly achievable. >> >> >> >> >>6. BGP Performance characteristics and Scalability >> >> >> In this section, we provide "order of magnitude" answers to the >> questions of how much link bandwidth, router memory and router CPU >> cycles the BGP protocol will consume under normal conditions. In >> particular, we will address the scalability of BGP and its >> limitations. >> >> >> >>6.1. Link bandwidth and CPU utilization >> >> >> Immediately after the initial BGP connection setup, BGP peers >> exchange complete set of routing information. If we denote the total >> number of routes in the Internet by N, the mean AS distance of the >> Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths by A, and assume that the networks are >> uniformly distributed among the autonomous systems, then the worst >> case amount of bandwidth consumed during the initial exchange between >> a pair of BGP speakers is >> >> BW = O(N + (M * A)) >> >> The following table illustrates the typical amount of bandwidth >> consumed during the initial exchange between a pair of BGP speakers >> based on the above assumptions (ignoring bandwidth consumed by the >> BGP Header). For purposes of the estimates here, we will calculate >> BW = 4 * (N + (M * A)). >> >> >> >>Meyer and Patel Section 6.1. [Page 9] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> # NLRI Mean AS Distance # AS's Bandwidth (MR) >> ---------- ---------------- ------ ---------------- >> 40,000 15 400 184,000 bytes >> 100,000 10 10,000 800,000 bytes >> 120,000 10 15,000 1,080,000 bytes >> 140,000 15 20,000 1,760,000 bytes >> >> [note that most of this bandwidth is consumed by the NLRI exchange] >> >> > >Is the caption for column 3 correct? It says "# AS's", which reads as "number of >AS's" while it seems it should be the number of unique paths. > > >> BGP was created specifically to reduce the size of the set of NLRI >> entries which have to be carried and exchanged by border routers. >> The aggregation scheme, defined in RFC 1519 [RFC1519], describes the >> provider-based aggregation scheme in use in today's Internet. >> >> Due to the advantages of advertising a few large aggregate blocks >> instead of many smaller class-based individual networks, it is >> difficult to estimate the actual reduction in bandwidth and >> processing that BGP has provided over BGP-3. If we simply enumerate >> all aggregate blocks into their individual class-based networks, we >> would not take into account "dead" space that has been reserved for >> future expansion. The best metric for determining the success of >> BGP's aggregation is to sample the number NLRI entries in the >> globally connected Internet today and compare it to projected growth >> rates before BGP was deployed. >> >> At the time of this writing, the full set of exterior routes carried >> by BGP is approximately 120,000 network entries [ROUTEVIEWS]. >> >> >> >>6.1.1. CPU utilization >> >> >> An important and fundamental feature of BGP is that BGP's CPU >> utilization depends only on the stability of the Internet. If the >> Internet is stable, then the only link bandwidth and router CPU >> cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE >> messages. The KEEPALIVE messages are exchanged only between peers. >> The suggested frequency of the exchange is 30 seconds. The KEEPALIVE >> messages are quite short (19 octets), and require virtually no >> processing. As a result, the bandwidth consumed by the KEEPALIVE >> messages is about 5 bits/sec. Operational experience confirms that >> the overhead (in terms of bandwidth and CPU) associated with the >> KEEPALIVE messages should be viewed as negligible. >> >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The >> >> > >While theoretically the text is correct and we could talk about periods of >stability and instability of the Internet, I wonder if this text is still >applicable from the practical perspective. I.e., the continuous churn that the >Internet BGP speakers experience ensures that they practically always have >something to process. > >Probably instead of talking about periods of "Internet stability" and "Internet >instability" we could talk about something like "periods of stable state among >BGP speakers when they do no have new updates to communicate to each other". > > > >>Meyer and Patel Section 6.1.1. [Page 10] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> greatest overhead per UPDATE message occurs when each UPDATE message >> contains only a single network. It should be pointed out that in >> practice routing changes exhibit strong locality with respect to the >> AS path. That is, routes that change are likely to have common AS >> path. In this case, multiple networks can be grouped into a single >> UPDATE message, thus significantly reducing the amount of bandwidth >> required (see also Appendix F.1 of [BGP4]). >> >> Since in the steady state the link bandwidth and router CPU cycles >> consumed by the BGP protocol are dependent only on the stability of >> the Internet, it follows that BGP should have no scaling problems in >> the areas of link bandwidth and router CPU utilization. >> >> > >Not sure I follow here. What is meant by the "steady state" here? If it means >convergence on a stable topology after the initial exchange of updates, then why >talk about "stability of the Internet"? In other words, if the Internet is >unstable then can we say that the BGP speakers are in steady state? In the lack >of topology changes, it seems that the consumption should instead depend on the >number of peers (affects KEEPALIVE processing) and the number of persistently >oscillating routes potentially present in the network... > > > >>This assumes >> that as the Internet grows, the overall stability of the inter-AS >> connectivity of the Internet can be controlled. >> >> > >please specify how it is assumed to be "controlled", e.g. through operational >practices. > > > >>In particular, while >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> >> > >232 or 2^32? > > > >> (where M is a slow-moving function describing the AS >> interconnectivity of the network), >> >> > >slow-moving or slow-growing? > > > >>no such bound can be formulated >> for the dynamic properties (i.e., stability) of BGP. Although, the >> dynamic properties of the network cannot be quantitatively bounded, >> they can be controlled within BGP. Beyond certain changes in the >> network, BGP can start to suppress such changes using BGP Route Flap >> Damping [RFC2439], pacing of its route updates, or BGP would be >> unable to keep up with the changes and force suppression of multiple >> changes over very short periods by causing the BGP peer socket to >> block on the sender. >> >> >> >>6.1.2. Memory requirements >> >> >> To quantify the worst case memory requirements for BGP, we denote the >> total number of networks in the Internet by N, the mean AS distance >> of the Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths as A. Then the worst case memory >> requirements (MR) can be expressed as >> >> >> MR = O(N + (M * A)) >> >> >> Since a mean AS distance M is a slow moving function of the >> interconnectivity ("meshiness") of the Internet, for all practical >> purposes the worst case router memory requirements are on the order >> of the total number of networks in the Internet times the number of >> peers the local system is peering with. We expect that the total >> number of networks in the Internet will grow much faster than the >> >> >> >>Meyer and Patel Section 6.1.2. [Page 11] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> average number of peers per router. As a result, BGP's memory >> scaling properties are linearly related to the total number of >> networks in the Internet. >> >> The following table illustrates typical memory requirements of a >> router running BGP. We denote average number of routes advertised by >> each peer as N, the total number of unique AS paths as A, the mean AS >> distance of the Internet as M (distance at the level of an autonomous >> system, expressed in terms of the number of autonomous systems), >> number of bytes required to store a route as R, and number of bytes >> required to store one AS in an AS path as P. It is assumed that each >> network is encoded as four bytes, each AS is encoded as two bytes, >> and each networks is reachable via some fraction of all of the peers >> (# BGP peers/per net). For purposes of the estimates here, we will >> calculate MR = ((N * R) + (M * A) * P) >> >> >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) >> ---------- ---------------- ------ ------------------- -------------- >> 100,000 20 3,000 20 1,040,000 >> 100,000 20 15,000 20 1,040,000 >> 120,000 10 15,000 100 75,000,000 >> 140,000 15 20,000 100 116,000,000 >> >> >> In analyzing BGP's memory requirements, we focus on the size of the >> forwarding table (and ignoring implementation details). In >> particular, we derive upper bounds for the size of the forwarding >> table. >> >> > >The above doesn't look like calculations for a forwarding table--the FIB doesn't >normally contact AS-PATH info or all possible paths to a destination. > > > >>11. Security Considerations >> >> >> This document presents an analysis of the BGP protocol and as such >> presents no new security implications for BGP. >> >> > >I'm afraid the IESG will expect to see some more here. Specifically, I would >suggest that the document talks about available security mechanisms, and the >analysis of how they affect processing overhead, BW, and scalability. >Certainly a pointer to the bgp-vuln document would be useful. > >Alex > > >_______________________________________________ >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 Thu Apr 15 13:44:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08380 for ; Thu, 15 Apr 2004 13:44: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 1BEAok-0007h3-38 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 13:38:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FHcQ9b029568 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 13:38:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAet-0004mT-QV for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 13:28:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07296 for ; Thu, 15 Apr 2004 13:28:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAer-0002XZ-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 13:28:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAdw-0002TX-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 13:27:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEAd2-0002Oy-00; Thu, 15 Apr 2004 13:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAWx-0002w2-Rr; Thu, 15 Apr 2004 13: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 1BEAMg-0000qG-M4 for idr@optimus.ietf.org; Thu, 15 Apr 2004 13:09:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05369 for ; Thu, 15 Apr 2004 13:09:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAMe-0000lw-00 for idr@ietf.org; Thu, 15 Apr 2004 13:09:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEALf-0000e0-00 for idr@ietf.org; Thu, 15 Apr 2004 13:08:25 -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 1BEAKj-0000Sc-00 for idr@ietf.org; Thu, 15 Apr 2004 13:07:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2004 09:17:27 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3FH6p7t029487; Thu, 15 Apr 2004 10:06:51 -0700 (PDT) Received: from cisco.com (keyupate-lnx.cisco.com [128.107.163.249]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ARI16143; Thu, 15 Apr 2004 10:05:06 -0700 (PDT) Message-ID: <407EC12A.6040109@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: Alex Zinin CC: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt References: <513361939.20040414192319@psg.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: Thu, 15 Apr 2004 10:06:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex: Thanks for the comments. We will incorporate them. -Keyur Alex Zinin wrote: >Folks- > >I have some technical comments regarding periods of stability and instability in >the Internet, BGP steady state, and the security considerations, plus several >editorial remarks. > >See inline below, please. > > > >>2.1. Key Features >> >> >... > > >> One of the most important path attributes is the Autonomous System >> Path, or AS_PATH. AS reachability information traverses the >> >> > ^^ > "As" > > > >> Internet, this information is augmented by the list of autonomous >> systems that have been traversed thus far, forming the AS_PATH. The >> AS_PATH allows straightforward suppression of the looping of routing >> information. In addition, the AS_PATH serves as a powerful and >> versatile mechanism for policy-based routing. >> >> BGP enhances the AS_PATH attribute to include sets of autonomous >> systems as well as lists via the AS_SET attribute. This extended >> format allows generated aggregate routes to carry path information >> from the more specific routes used to generate the aggregate. It >> should be noted however, that as of this writing, AS_SETs are rarely >> used in the Internet [ROUTEVIEWS]. >> >> >> >>2.2. BGP Algorithms >> >> >> BGP uses an algorithm that is neither a pure distance vector >> algorithm or a pure link state algorithm. It is instead a modified >> distance vector algorithm referred to as a "Path Vector" algorithm >> that uses path information to avoid traditional distance vector >> problems. Each route within BGP pairs destination with path >> information to that destination. Path information (also known as >> AS_PATH information) is stored within the AS_PATH attribute in BGP. >> This allows BGP to reconstruct large portions of overall topology >> whenever required. >> >> > >I've always been uncomfortable with documents saying that BGP reconstructs the >overall topology. It doesn't really do this like the link-state protocols do, >for example. > > > >> BGP uses an incremental update strategy in order to conserve >> bandwidth and processing power. That is, after initial exchange of >> complete routing information, a pair of BGP routers exchanges only >> changes to that information. Such an incremental update design >> requires reliable transport between a pair of BGP routers to function >> correctly. BGP solves this problem by using TCP for reliable >> transport. >> >> > >Should also note that use of TCP as the transport mechanism helps control >congestion and CPU utilization. > > > >> In addition to incremental updates, BGP has added the concept of >> route aggregation so that information about groups of networks may be >> >> >> >>Meyer and Patel Section 2.2. [Page 5] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> aggregated and sent as a single Network Layer Reachability (NLRI). >> >> > >this doesn't read well. Neither "reachability" nor "information" are countable. >"Single prefix" instead? > > > >> Finally, note that BGP is a self-contained protocol. That is, BGP >> specifies how routing information is exchanged both between BGP >> speakers in different autonomous systems, and between BGP speakers >> within a single autonomous system. >> >> >> >>2.3. BGP Finite State Machine (FSM) >> >> >> The BGP FSM is a set of rules that are applied to a BGP speaker's set >> of configured peers for the BGP operation. A BGP implementation >> requires that a BGP speaker must connect to and listen on TCP port >> 179 for accepting any new BGP connections from its peers. The BGP >> Finite State Machine, or FSM, must be initiated and maintained for >> each new incoming and outgoing peer connections. However, in steady >> state operation, there will be only one BGP FSM per connection per >> peer. >> >> There may exist a temporary period where in a BGP peer may have >> separate incoming and outgoing connections resulting into two >> different BGP FSMs for a peer (instead of one). This can be resolved >> following BGP connection collision rules defined in the [BGP4]. >> >> Following are different states of BGP FSM for its peers: >> >> IDLE: State when BGP peer refuses any incoming >> connections. >> >> CONNECT: State in which BGP peer is waiting for >> its TCP connection to be completed. >> >> ACTIVE: State in which BGP peer is trying to acquire a >> peer by listening and accepting TCP connection. >> >> OPENSENT: BGP peer is waiting for OPEN message from its >> peer. >> >> OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION >> message from its peer. >> >> ESTABLISHED: BGP peer connection is established and exchanges >> UPDATE, NOTIFICATION, and KEEPALIVE messages with >> its peer. >> >> There are different BGP events that operate on above mentioned states >> >> >> >>Meyer and Patel Section 2.3. [Page 6] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> of BGP FSM for its peers. These BGP events are used for initiating and >> terminating peer connections. They also assist BGP in identifying any >> persistent peer connection oscillations and provide a mechanism >> for controlling them. >> >> Following are different BGP events: >> >> Manual Start: Manually start the peer connection. >> >> Manual Stop: Manually stop the peer connection. >> >> Automatic Start: Local system automatically starts the peer >> connection. >> >> Manual start with >> passive TCP flag: Local system administrator manually starts the >> peer connection with peer in passive mode. >> >> Automatic start >> with passive TCP flag: Local system administrator automatically starts >> the peer connection with peer in passive mode. >> >> Automatic start >> with bgp_stop_flap >> option set: Local system administrator automatically starts >> the peer connection with peer oscillation >> damping enabled. >> >> Automatic start with >> bgp_stop_flap option >> set and passive TCP >> establishment >> option set: Local system administrator automatically starts >> the peer connection with peer oscillation >> damping enabled and with peer in passive mode. >> >> Automatic stop: Local system automatically stops the >> BGP connection. >> >> Both, Manual Start and Manual Stop are mandatory BGP events. All >> other events are optional. >> >> >> > >Ummmm... the above are "administrative" events only. There are other events in >the FSM, and most of other events are mandatory. > > > >> >> >> >> >> >> >>Meyer and Patel Section 2.3. [Page 7] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >>3. BGP Capabilities >> >> >> The BGP Capability mechanism [RFC2842] provides an easy and flexible >> way to introduce new features within the protocol. In particular, >> the BGP capability mechanism allows peers to negotiate various >> optional features during startup. This allows the base BGP protocol >> to contain only essential functionality, while at the same time >> providing a flexible mechanism for signaling protocol extensions. >> >> >> >>4. BGP Persistent Peer Oscillations >> >> >> Ideally, whenever a BGP speaker detects an error in any peer >> connection, it shuts down the peer and changes its FSM state to IDLE. >> BGP speaker requires a Start event to re-initiate its idle peer >> connection. If the error remains persistent and BGP speaker >> generates Start event automatically then it may result in persistent >> peer flapping. However, although peer oscillation is found to be >> wide-spread in BGP implementations, methods for preventing persistent >> peer oscillations are outside the scope of base BGP protocol >> specification. >> >> >> >>5. Implementation Guidelines >> >> >> A robust BGP implementation is work conserving. This means that if >> the number of prefixes is bound, arbitrarily high levels of route >> change can be tolerated with bounded impact on route convergence for >> occasionally changes in generally stable routes. >> >> > >"occasional"? > > > >> A BGP implementation under high load conditions should empty as much >> inbound routing updates from its input streams, processing only the >> most recent route if the route for a given NLRI changes multiple >> times. TCP also provides blocking on the writes on the sender side. >> A BGP implementation under load should expect blocks on write calls >> and send only the most recent routes when sockets unblock rather than >> sending entire history. >> >> A robust implementation of BGP should have the following >> characteristics: >> 1. It is able to operate in almost arbitrarily high levels >> of route flap without loosing peerings (failing to send >> keepalives) or loosing other protocol adjacencies as a >> >> >> >>Meyer and Patel Section 5. [Page 8] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> result of BGP load. >> >> 2. Instability of a subset of routes should not affect the >> route advertisements or forwarding associated with the set >> of stable routes. >> >> 3. High levels of instability and peers of different CPU speed >> or load resulting in faster or slower processing of routes >> should not cause instability and should have a bounded >> impact on the convergence time for generally stable routes. >> >> Numerous robust BGP implementations exist. Producing a robust >> implementation is not a trivial matter but clearly achievable. >> >> >> >> >>6. BGP Performance characteristics and Scalability >> >> >> In this section, we provide "order of magnitude" answers to the >> questions of how much link bandwidth, router memory and router CPU >> cycles the BGP protocol will consume under normal conditions. In >> particular, we will address the scalability of BGP and its >> limitations. >> >> >> >>6.1. Link bandwidth and CPU utilization >> >> >> Immediately after the initial BGP connection setup, BGP peers >> exchange complete set of routing information. If we denote the total >> number of routes in the Internet by N, the mean AS distance of the >> Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths by A, and assume that the networks are >> uniformly distributed among the autonomous systems, then the worst >> case amount of bandwidth consumed during the initial exchange between >> a pair of BGP speakers is >> >> BW = O(N + (M * A)) >> >> The following table illustrates the typical amount of bandwidth >> consumed during the initial exchange between a pair of BGP speakers >> based on the above assumptions (ignoring bandwidth consumed by the >> BGP Header). For purposes of the estimates here, we will calculate >> BW = 4 * (N + (M * A)). >> >> >> >>Meyer and Patel Section 6.1. [Page 9] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> # NLRI Mean AS Distance # AS's Bandwidth (MR) >> ---------- ---------------- ------ ---------------- >> 40,000 15 400 184,000 bytes >> 100,000 10 10,000 800,000 bytes >> 120,000 10 15,000 1,080,000 bytes >> 140,000 15 20,000 1,760,000 bytes >> >> [note that most of this bandwidth is consumed by the NLRI exchange] >> >> > >Is the caption for column 3 correct? It says "# AS's", which reads as "number of >AS's" while it seems it should be the number of unique paths. > > >> BGP was created specifically to reduce the size of the set of NLRI >> entries which have to be carried and exchanged by border routers. >> The aggregation scheme, defined in RFC 1519 [RFC1519], describes the >> provider-based aggregation scheme in use in today's Internet. >> >> Due to the advantages of advertising a few large aggregate blocks >> instead of many smaller class-based individual networks, it is >> difficult to estimate the actual reduction in bandwidth and >> processing that BGP has provided over BGP-3. If we simply enumerate >> all aggregate blocks into their individual class-based networks, we >> would not take into account "dead" space that has been reserved for >> future expansion. The best metric for determining the success of >> BGP's aggregation is to sample the number NLRI entries in the >> globally connected Internet today and compare it to projected growth >> rates before BGP was deployed. >> >> At the time of this writing, the full set of exterior routes carried >> by BGP is approximately 120,000 network entries [ROUTEVIEWS]. >> >> >> >>6.1.1. CPU utilization >> >> >> An important and fundamental feature of BGP is that BGP's CPU >> utilization depends only on the stability of the Internet. If the >> Internet is stable, then the only link bandwidth and router CPU >> cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE >> messages. The KEEPALIVE messages are exchanged only between peers. >> The suggested frequency of the exchange is 30 seconds. The KEEPALIVE >> messages are quite short (19 octets), and require virtually no >> processing. As a result, the bandwidth consumed by the KEEPALIVE >> messages is about 5 bits/sec. Operational experience confirms that >> the overhead (in terms of bandwidth and CPU) associated with the >> KEEPALIVE messages should be viewed as negligible. >> >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The >> >> > >While theoretically the text is correct and we could talk about periods of >stability and instability of the Internet, I wonder if this text is still >applicable from the practical perspective. I.e., the continuous churn that the >Internet BGP speakers experience ensures that they practically always have >something to process. > >Probably instead of talking about periods of "Internet stability" and "Internet >instability" we could talk about something like "periods of stable state among >BGP speakers when they do no have new updates to communicate to each other". > > > >>Meyer and Patel Section 6.1.1. [Page 10] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> greatest overhead per UPDATE message occurs when each UPDATE message >> contains only a single network. It should be pointed out that in >> practice routing changes exhibit strong locality with respect to the >> AS path. That is, routes that change are likely to have common AS >> path. In this case, multiple networks can be grouped into a single >> UPDATE message, thus significantly reducing the amount of bandwidth >> required (see also Appendix F.1 of [BGP4]). >> >> Since in the steady state the link bandwidth and router CPU cycles >> consumed by the BGP protocol are dependent only on the stability of >> the Internet, it follows that BGP should have no scaling problems in >> the areas of link bandwidth and router CPU utilization. >> >> > >Not sure I follow here. What is meant by the "steady state" here? If it means >convergence on a stable topology after the initial exchange of updates, then why >talk about "stability of the Internet"? In other words, if the Internet is >unstable then can we say that the BGP speakers are in steady state? In the lack >of topology changes, it seems that the consumption should instead depend on the >number of peers (affects KEEPALIVE processing) and the number of persistently >oscillating routes potentially present in the network... > > > >>This assumes >> that as the Internet grows, the overall stability of the inter-AS >> connectivity of the Internet can be controlled. >> >> > >please specify how it is assumed to be "controlled", e.g. through operational >practices. > > > >>In particular, while >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> >> > >232 or 2^32? > > > >> (where M is a slow-moving function describing the AS >> interconnectivity of the network), >> >> > >slow-moving or slow-growing? > > > >>no such bound can be formulated >> for the dynamic properties (i.e., stability) of BGP. Although, the >> dynamic properties of the network cannot be quantitatively bounded, >> they can be controlled within BGP. Beyond certain changes in the >> network, BGP can start to suppress such changes using BGP Route Flap >> Damping [RFC2439], pacing of its route updates, or BGP would be >> unable to keep up with the changes and force suppression of multiple >> changes over very short periods by causing the BGP peer socket to >> block on the sender. >> >> >> >>6.1.2. Memory requirements >> >> >> To quantify the worst case memory requirements for BGP, we denote the >> total number of networks in the Internet by N, the mean AS distance >> of the Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths as A. Then the worst case memory >> requirements (MR) can be expressed as >> >> >> MR = O(N + (M * A)) >> >> >> Since a mean AS distance M is a slow moving function of the >> interconnectivity ("meshiness") of the Internet, for all practical >> purposes the worst case router memory requirements are on the order >> of the total number of networks in the Internet times the number of >> peers the local system is peering with. We expect that the total >> number of networks in the Internet will grow much faster than the >> >> >> >>Meyer and Patel Section 6.1.2. [Page 11] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> average number of peers per router. As a result, BGP's memory >> scaling properties are linearly related to the total number of >> networks in the Internet. >> >> The following table illustrates typical memory requirements of a >> router running BGP. We denote average number of routes advertised by >> each peer as N, the total number of unique AS paths as A, the mean AS >> distance of the Internet as M (distance at the level of an autonomous >> system, expressed in terms of the number of autonomous systems), >> number of bytes required to store a route as R, and number of bytes >> required to store one AS in an AS path as P. It is assumed that each >> network is encoded as four bytes, each AS is encoded as two bytes, >> and each networks is reachable via some fraction of all of the peers >> (# BGP peers/per net). For purposes of the estimates here, we will >> calculate MR = ((N * R) + (M * A) * P) >> >> >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) >> ---------- ---------------- ------ ------------------- -------------- >> 100,000 20 3,000 20 1,040,000 >> 100,000 20 15,000 20 1,040,000 >> 120,000 10 15,000 100 75,000,000 >> 140,000 15 20,000 100 116,000,000 >> >> >> In analyzing BGP's memory requirements, we focus on the size of the >> forwarding table (and ignoring implementation details). In >> particular, we derive upper bounds for the size of the forwarding >> table. >> >> > >The above doesn't look like calculations for a forwarding table--the FIB doesn't >normally contact AS-PATH info or all possible paths to a destination. > > > >>11. Security Considerations >> >> >> This document presents an analysis of the BGP protocol and as such >> presents no new security implications for BGP. >> >> > >I'm afraid the IESG will expect to see some more here. Specifically, I would >suggest that the document talks about available security mechanisms, and the >analysis of how they affect processing overhead, BW, and scalability. >Certainly a pointer to the bgp-vuln document would be useful. > >Alex > > >_______________________________________________ >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 Thu Apr 15 16:02:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23262 for ; Thu, 15 Apr 2004 16:02:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BED4a-0006iF-Sl for idr-archive@ietf.org; Thu, 15 Apr 2004 16:02:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BED3n-0006g8-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 16:02:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BED3S-0006dR-00; Thu, 15 Apr 2004 16: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 1BECyr-0007ZE-3v; Thu, 15 Apr 2004 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAF8-0006sO-TA for idr@optimus.ietf.org; Thu, 15 Apr 2004 13:01:38 -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 NAA04895 for ; Thu, 15 Apr 2004 13:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAF7-0007cs-00 for idr@ietf.org; Thu, 15 Apr 2004 13:01:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAEK-0007UH-00 for idr@ietf.org; Thu, 15 Apr 2004 13:00:48 -0400 Received: from gizmo.fireflynetworks.net ([207.76.173.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEADO-0007Jl-00 for idr@ietf.org; Thu, 15 Apr 2004 12:59:51 -0400 Received: from jb.colo.dca.webact.com (jb.colo.dca.webact.com [207.76.173.57]) by gizmo.fireflynetworks.net (8.12.11/8.12.11) with ESMTP id i3FH0jO8094320; Thu, 15 Apr 2004 13:00:45 -0400 (EDT) (envelope-from jsb@barrows.net) From: Jeff Barrows X-X-Sender: jsb@gizmo.fireflynetworks.net To: Pekka Savola cc: Yakov Rekhter , Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message-ID: <20040415124633.I87123-100000@gizmo.fireflynetworks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 13:00:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Not to limit cool/smart thinking, but I believe that the level of effort and/or complexity here exceeds the return. This has never been an issue in any of the major SP networks that I've played with. While protecting at the edges is of interest, sharing or communicating policy [such as thresholds] has been more of an area of concern (risk-wise) than a priority. An e-mail, phone call, or contractual arrangement should suffice in other cases. - jsb > Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) > From: Pekka Savola > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > On Thu, 15 Apr 2004, Yakov Rekhter wrote: > > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > > as an IDR WG document. Please send comments to the list. The deadline > > for comments is April 29, 2004. > > The applicability does not seem to be sufficiently clear. > > That is, people use prefix limits for a *reason*. Once set, they're > set until they are changed. There's no urgent need to specify > anything here. > > However, I agree that it might not hurt to have some option that could > be used to inform the peer on your limits, so that: > - the operator of the peer could notice this when examining the > neighbor's info (i.e., when contemplating about advertising new > prefixes), or > - if the peer exceeded the prefix limits, the peer's operator would > notice that a warning/stop threshold has been reached (this could > result in an SNMP trap, flashing led, or whatever.) > > I fail to see a need for anything more than that, and the current > document *seems* to be more complex than that. > > Unless I'm mistaken, I'm not sure if going forward with this draft is > a good idea. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 16:19:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24401 for ; Thu, 15 Apr 2004 16:19:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BED8v-00017c-3n for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 16:07:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FK7PSG004306 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 16:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BED4e-0000SL-37 for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 16:03:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23292 for ; Thu, 15 Apr 2004 16:02:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BED4c-0006iP-Ir for idr-web-archive@ietf.org; Thu, 15 Apr 2004 16:02:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BED3o-0006gO-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 16:02:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BED3S-0006dR-00; Thu, 15 Apr 2004 16: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 1BECyr-0007ZE-3v; Thu, 15 Apr 2004 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAF8-0006sO-TA for idr@optimus.ietf.org; Thu, 15 Apr 2004 13:01:38 -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 NAA04895 for ; Thu, 15 Apr 2004 13:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAF7-0007cs-00 for idr@ietf.org; Thu, 15 Apr 2004 13:01:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAEK-0007UH-00 for idr@ietf.org; Thu, 15 Apr 2004 13:00:48 -0400 Received: from gizmo.fireflynetworks.net ([207.76.173.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEADO-0007Jl-00 for idr@ietf.org; Thu, 15 Apr 2004 12:59:51 -0400 Received: from jb.colo.dca.webact.com (jb.colo.dca.webact.com [207.76.173.57]) by gizmo.fireflynetworks.net (8.12.11/8.12.11) with ESMTP id i3FH0jO8094320; Thu, 15 Apr 2004 13:00:45 -0400 (EDT) (envelope-from jsb@barrows.net) From: Jeff Barrows X-X-Sender: jsb@gizmo.fireflynetworks.net To: Pekka Savola cc: Yakov Rekhter , Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message-ID: <20040415124633.I87123-100000@gizmo.fireflynetworks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 13:00:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Not to limit cool/smart thinking, but I believe that the level of effort and/or complexity here exceeds the return. This has never been an issue in any of the major SP networks that I've played with. While protecting at the edges is of interest, sharing or communicating policy [such as thresholds] has been more of an area of concern (risk-wise) than a priority. An e-mail, phone call, or contractual arrangement should suffice in other cases. - jsb > Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) > From: Pekka Savola > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > On Thu, 15 Apr 2004, Yakov Rekhter wrote: > > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > > as an IDR WG document. Please send comments to the list. The deadline > > for comments is April 29, 2004. > > The applicability does not seem to be sufficiently clear. > > That is, people use prefix limits for a *reason*. Once set, they're > set until they are changed. There's no urgent need to specify > anything here. > > However, I agree that it might not hurt to have some option that could > be used to inform the peer on your limits, so that: > - the operator of the peer could notice this when examining the > neighbor's info (i.e., when contemplating about advertising new > prefixes), or > - if the peer exceeded the prefix limits, the peer's operator would > notice that a warning/stop threshold has been reached (this could > result in an SNMP trap, flashing led, or whatever.) > > I fail to see a need for anything more than that, and the current > document *seems* to be more complex than that. > > Unless I'm mistaken, I'm not sure if going forward with this draft is > a good idea. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 16:27:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24883 for ; Thu, 15 Apr 2004 16:27:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDSh-0000Dp-Il for idr-archive@ietf.org; Thu, 15 Apr 2004 16:27:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDRq-0000Aj-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 16:26:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEDR3-00007f-00; Thu, 15 Apr 2004 16:26:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDLB-0003fN-6a; Thu, 15 Apr 2004 16:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDBO-0001Ob-So for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:09:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23737 for ; Thu, 15 Apr 2004 16:09:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDBN-00076g-2s for idr@ietf.org; Thu, 15 Apr 2004 16:09:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDAR-00072d-00 for idr@ietf.org; Thu, 15 Apr 2004 16:09:00 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BED9d-0006wb-00 for idr@ietf.org; Thu, 15 Apr 2004 16:08:09 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D30D62D4856 for ; Thu, 15 Apr 2004 16:05:44 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22604-03-6 for ; Thu, 15 Apr 2004 16:05:29 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 344222D4864 for ; Thu, 15 Apr 2004 16:05:29 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQjJH5Ea3lSLG06TrGjjOWZyyaGsgAAC1hQ From: "Susan Hares" To: "Jeff Barrows" , "Pekka Savola" Cc: "Yakov Rekhter" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:05:29 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Jeff: As an editor of the draft, I'd like a little bit more detail on what you think exceeds the level of effort or complexity. The three parameters (warning, stop receive, drop) [sub-codes 1-3] or the additional parameters (sub-codes 4,5,6,etc).=20 Sue PS - the additional pieces were put in response to a discussion at the IETF. -----Original Message----- From: Jeff Barrows [mailto:jsb@barrows.net] Sent: Thursday, April 15, 2004 1:01 PM To: Pekka Savola Cc: Yakov Rekhter; idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Not to limit cool/smart thinking, but I believe that the level of effort and/or complexity here exceeds the return. This has never been an issue in any of the major SP networks that I've played with. While protecting at the edges is of interest, sharing or communicating policy [such as thresholds] has been more of an area of concern (risk-wise) than a priority. An e-mail, phone call, or contractual arrangement should suffice in other cases. - jsb > Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) > From: Pekka Savola > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > On Thu, 15 Apr 2004, Yakov Rekhter wrote: > > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > > as an IDR WG document. Please send comments to the list. The = deadline > > for comments is April 29, 2004. > > The applicability does not seem to be sufficiently clear. > > That is, people use prefix limits for a *reason*. Once set, they're > set until they are changed. There's no urgent need to specify > anything here. > > However, I agree that it might not hurt to have some option that could > be used to inform the peer on your limits, so that: > - the operator of the peer could notice this when examining the > neighbor's info (i.e., when contemplating about advertising new > prefixes), or > - if the peer exceeded the prefix limits, the peer's operator would > notice that a warning/stop threshold has been reached (this could > result in an SNMP trap, flashing led, or whatever.) > > I fail to see a need for anything more than that, and the current > document *seems* to be more complex than that. > > Unless I'm mistaken, I'm not sure if going forward with this draft is > a good idea. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 16:39:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25433 for ; Thu, 15 Apr 2004 16:39: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 1BEDYx-0006On-0D for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 16:34:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FKYI9P024592 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 16:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDSl-0005Dh-Pb for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 16:27: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 QAA24911 for ; Thu, 15 Apr 2004 16:27:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDSj-0000EA-Vn for idr-web-archive@ietf.org; Thu, 15 Apr 2004 16:27:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDRs-0000Az-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 16:27:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEDR3-00007f-00; Thu, 15 Apr 2004 16:26:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDLB-0003fN-6a; Thu, 15 Apr 2004 16:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDBO-0001Ob-So for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:09:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23737 for ; Thu, 15 Apr 2004 16:09:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDBN-00076g-2s for idr@ietf.org; Thu, 15 Apr 2004 16:09:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDAR-00072d-00 for idr@ietf.org; Thu, 15 Apr 2004 16:09:00 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BED9d-0006wb-00 for idr@ietf.org; Thu, 15 Apr 2004 16:08:09 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D30D62D4856 for ; Thu, 15 Apr 2004 16:05:44 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22604-03-6 for ; Thu, 15 Apr 2004 16:05:29 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 344222D4864 for ; Thu, 15 Apr 2004 16:05:29 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQjJH5Ea3lSLG06TrGjjOWZyyaGsgAAC1hQ From: "Susan Hares" To: "Jeff Barrows" , "Pekka Savola" Cc: "Yakov Rekhter" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:05:29 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jeff: As an editor of the draft, I'd like a little bit more detail on what you think exceeds the level of effort or complexity. The three parameters (warning, stop receive, drop) [sub-codes 1-3] or the additional parameters (sub-codes 4,5,6,etc).=20 Sue PS - the additional pieces were put in response to a discussion at the IETF. -----Original Message----- From: Jeff Barrows [mailto:jsb@barrows.net] Sent: Thursday, April 15, 2004 1:01 PM To: Pekka Savola Cc: Yakov Rekhter; idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Not to limit cool/smart thinking, but I believe that the level of effort and/or complexity here exceeds the return. This has never been an issue in any of the major SP networks that I've played with. While protecting at the edges is of interest, sharing or communicating policy [such as thresholds] has been more of an area of concern (risk-wise) than a priority. An e-mail, phone call, or contractual arrangement should suffice in other cases. - jsb > Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) > From: Pekka Savola > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > On Thu, 15 Apr 2004, Yakov Rekhter wrote: > > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > > as an IDR WG document. Please send comments to the list. The = deadline > > for comments is April 29, 2004. > > The applicability does not seem to be sufficiently clear. > > That is, people use prefix limits for a *reason*. Once set, they're > set until they are changed. There's no urgent need to specify > anything here. > > However, I agree that it might not hurt to have some option that could > be used to inform the peer on your limits, so that: > - the operator of the peer could notice this when examining the > neighbor's info (i.e., when contemplating about advertising new > prefixes), or > - if the peer exceeded the prefix limits, the peer's operator would > notice that a warning/stop threshold has been reached (this could > result in an SNMP trap, flashing led, or whatever.) > > I fail to see a need for anything more than that, and the current > document *seems* to be more complex than that. > > Unless I'm mistaken, I'm not sure if going forward with this draft is > a good idea. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 16:40:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25556 for ; Thu, 15 Apr 2004 16:40:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDfJ-0000m0-T8 for idr-archive@ietf.org; Thu, 15 Apr 2004 16:40:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDeS-0000jz-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 16:40:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEDe6-0000iF-00; Thu, 15 Apr 2004 16:39:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDZe-0006R0-9f; Thu, 15 Apr 2004 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDSv-0005LU-CO for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:28:05 -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 QAA24964 for ; Thu, 15 Apr 2004 16:28:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDSt-0000FU-Hh for idr@ietf.org; Thu, 15 Apr 2004 16:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDS5-0000D2-00 for idr@ietf.org; Thu, 15 Apr 2004 16:27:14 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BEDRc-00008L-00 for idr@ietf.org; Thu, 15 Apr 2004 16:26:44 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 491B52D4868 for ; Thu, 15 Apr 2004 16:26:15 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23531-01 for ; Thu, 15 Apr 2004 16:26:00 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BC1E22D482C for ; Thu, 15 Apr 2004 16:26:00 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQjATT+r3Tcj5ZtS5KO1S3UzQ+QSAAJVH+g From: "Susan Hares" To: "Pekka Savola" , "Yakov Rekhter" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:26:00 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Pekka: This is in my hat as an editor of the draft. Not in my co-chair hat.=20 =20 Can you clarify something here: 1) Your need - informing the remote peer of warning limits, stop receive limits, and drop limits and SNMP traps, logs etcs is the basis for the draft. 2) Providers we talk to had 2 cases: =09 1) creeping VPN prefix limits 2) dump of whole routing table The need to treat the two differently. 3) Set until changed - that's the rub The providers wanted to negotiate the capabilties and upgrade the capabilities without dropping the connect. Is that what you mean as well? If so, could you comment on what is complex. History:=20 We started this out with capabilities on open, and dynamic capabilities. Due to some vendor's request to include other mechanism (ORF, Soft Notify) to support the dynamic features -=20 we added the rest. Other service providers said, Love the function but could you do it by prefix lengths. =20 In an effort to get something working for all these folks, we made these other features optional. =20 What part don't you like? Cause everything you stated you wanted -- is the basic part of the initial draft? Did you dis-like the additions (ORF, Soft Notify) and or the optional sub-codes?=20 Do you think we should go back to the initial draft simplistic model? Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, April 15, 2004 11:29 AM To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document On Thu, 15 Apr 2004, Yakov Rekhter wrote: > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004.=20 The applicability does not seem to be sufficiently clear. That is, people use prefix limits for a *reason*. Once set, they're=20 set until they are changed. There's no urgent need to specify=20 anything here. However, I agree that it might not hurt to have some option that could=20 be used to inform the peer on your limits, so that: - the operator of the peer could notice this when examining the=20 neighbor's info (i.e., when contemplating about advertising new=20 prefixes), or - if the peer exceeded the prefix limits, the peer's operator would=20 notice that a warning/stop threshold has been reached (this could=20 result in an SNMP trap, flashing led, or whatever.) I fail to see a need for anything more than that, and the current=20 document *seems* to be more complex than that. Unless I'm mistaken, I'm not sure if going forward with this draft is=20 a good idea. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 16:47:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25974 for ; Thu, 15 Apr 2004 16:47: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 1BEDk0-0000bk-Ix for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 16:45:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FKjiPG002330 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 16:45:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDfN-0008BS-BA for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 16:40:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25582 for ; Thu, 15 Apr 2004 16:40:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDfL-0000mC-BG for idr-web-archive@ietf.org; Thu, 15 Apr 2004 16:40:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDeT-0000kD-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 16:40:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEDe6-0000iF-00; Thu, 15 Apr 2004 16:39:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDZe-0006R0-9f; Thu, 15 Apr 2004 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDSv-0005LU-CO for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:28:05 -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 QAA24964 for ; Thu, 15 Apr 2004 16:28:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDSt-0000FU-Hh for idr@ietf.org; Thu, 15 Apr 2004 16:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDS5-0000D2-00 for idr@ietf.org; Thu, 15 Apr 2004 16:27:14 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BEDRc-00008L-00 for idr@ietf.org; Thu, 15 Apr 2004 16:26:44 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 491B52D4868 for ; Thu, 15 Apr 2004 16:26:15 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23531-01 for ; Thu, 15 Apr 2004 16:26:00 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BC1E22D482C for ; Thu, 15 Apr 2004 16:26:00 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQjATT+r3Tcj5ZtS5KO1S3UzQ+QSAAJVH+g From: "Susan Hares" To: "Pekka Savola" , "Yakov Rekhter" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:26:00 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka: This is in my hat as an editor of the draft. Not in my co-chair hat.=20 =20 Can you clarify something here: 1) Your need - informing the remote peer of warning limits, stop receive limits, and drop limits and SNMP traps, logs etcs is the basis for the draft. 2) Providers we talk to had 2 cases: =09 1) creeping VPN prefix limits 2) dump of whole routing table The need to treat the two differently. 3) Set until changed - that's the rub The providers wanted to negotiate the capabilties and upgrade the capabilities without dropping the connect. Is that what you mean as well? If so, could you comment on what is complex. History:=20 We started this out with capabilities on open, and dynamic capabilities. Due to some vendor's request to include other mechanism (ORF, Soft Notify) to support the dynamic features -=20 we added the rest. Other service providers said, Love the function but could you do it by prefix lengths. =20 In an effort to get something working for all these folks, we made these other features optional. =20 What part don't you like? Cause everything you stated you wanted -- is the basic part of the initial draft? Did you dis-like the additions (ORF, Soft Notify) and or the optional sub-codes?=20 Do you think we should go back to the initial draft simplistic model? Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, April 15, 2004 11:29 AM To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document On Thu, 15 Apr 2004, Yakov Rekhter wrote: > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004.=20 The applicability does not seem to be sufficiently clear. That is, people use prefix limits for a *reason*. Once set, they're=20 set until they are changed. There's no urgent need to specify=20 anything here. However, I agree that it might not hurt to have some option that could=20 be used to inform the peer on your limits, so that: - the operator of the peer could notice this when examining the=20 neighbor's info (i.e., when contemplating about advertising new=20 prefixes), or - if the peer exceeded the prefix limits, the peer's operator would=20 notice that a warning/stop threshold has been reached (this could=20 result in an SNMP trap, flashing led, or whatever.) I fail to see a need for anything more than that, and the current=20 document *seems* to be more complex than that. Unless I'm mistaken, I'm not sure if going forward with this draft is=20 a good idea. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 15 17:29:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28884 for ; Thu, 15 Apr 2004 17:29:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEEQQ-0005FH-S1 for idr-archive@ietf.org; Thu, 15 Apr 2004 17:29:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEEOs-0004za-00 for idr-archive@ietf.org; Thu, 15 Apr 2004 17:27:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEENQ-0004jw-00; Thu, 15 Apr 2004 17:26:28 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEENR-0000lv-4Q; Thu, 15 Apr 2004 17:26:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDke-0000rz-Pj; Thu, 15 Apr 2004 16:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDfg-0008L6-EO for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:41:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25607; Thu, 15 Apr 2004 16:41:13 -0400 (EDT) Message-Id: <200404152041.QAA25607@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-09.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:41:13 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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, et al. Filename : draft-ietf-idr-restart-09.txt Pages : 10 Date : 2004-4-15 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-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-restart-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: <2004-4-15153844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15153844.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 15 18:03:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00125 for ; Thu, 15 Apr 2004 18:03: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 1BEEkg-00062J-9T for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 17:50:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FLoUl6023199 for idr-archive@odin.ietf.org; Thu, 15 Apr 2004 17: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 1BEEQW-0007Ty-M0 for idr-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 17:29: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 RAA28913 for ; Thu, 15 Apr 2004 17:29:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEEQU-0005Fn-DM for idr-web-archive@ietf.org; Thu, 15 Apr 2004 17:29:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEEOv-000509-00 for idr-web-archive@ietf.org; Thu, 15 Apr 2004 17:28:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEENQ-0004jw-00; Thu, 15 Apr 2004 17:26:28 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEENR-0000lv-4Q; Thu, 15 Apr 2004 17:26:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDke-0000rz-Pj; Thu, 15 Apr 2004 16:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDfg-0008L6-EO for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:41:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25607; Thu, 15 Apr 2004 16:41:13 -0400 (EDT) Message-Id: <200404152041.QAA25607@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-09.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:41:13 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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, et al. Filename : draft-ietf-idr-restart-09.txt Pages : 10 Date : 2004-4-15 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-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-restart-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: <2004-4-15153844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15153844.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 16 17:38:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11901 for ; Fri, 16 Apr 2004 17:38:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEb2U-0003is-7N for idr-archive@ietf.org; Fri, 16 Apr 2004 17:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEb1V-0003gA-00 for idr-archive@ietf.org; Fri, 16 Apr 2004 17:37:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEb0Y-0003ch-00; Fri, 16 Apr 2004 17:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxK-0008QB-4l; Fri, 16 Apr 2004 17:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEao0-0005qb-RY for idr@optimus.ietf.org; Fri, 16 Apr 2004 17:23: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 RAA11133 for ; Fri, 16 Apr 2004 17:23:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEany-0002uo-JO for idr@ietf.org; Fri, 16 Apr 2004 17:23:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEan4-0002tI-00 for idr@ietf.org; Fri, 16 Apr 2004 17:22:27 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEamS-0002pR-00 for idr@ietf.org; Fri, 16 Apr 2004 17:21:48 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3GLLIl98120 for ; Fri, 16 Apr 2004 14:21:18 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3GLLDJ87448 for ; Fri, 16 Apr 2004 14:21:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404162121.i3GLLDJ87448@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72719.1082150473.1@juniper.net> From: Yakov Rekhter Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-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, 16 Apr 2004 14:21:13 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, During the Last Call it would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 13:36:09 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. - ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - - --OtherAccess-- - - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 16 17:42:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12110 for ; Fri, 16 Apr 2004 17:42:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEb6l-0003yH-Kw for idr-archive@ietf.org; Fri, 16 Apr 2004 17:42:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEb5o-0003uj-00 for idr-archive@ietf.org; Fri, 16 Apr 2004 17:41:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEb5G-0003pe-00; Fri, 16 Apr 2004 17:41:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxL-0008Se-1P; Fri, 16 Apr 2004 17:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEapt-0006CJ-53 for idr@optimus.ietf.org; Fri, 16 Apr 2004 17:25:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11153 for ; Fri, 16 Apr 2004 17:25:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEapq-0002xN-OV for idr@ietf.org; Fri, 16 Apr 2004 17:25:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaos-0002vu-00 for idr@ietf.org; Fri, 16 Apr 2004 17:24:19 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEao1-0002u2-00 for idr@ietf.org; Fri, 16 Apr 2004 17:23:25 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3GLMtl98124 for ; Fri, 16 Apr 2004 14:22:55 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3GLMoJ87986 for ; Fri, 16 Apr 2004 14:22:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404162122.i3GLMoJ87986@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72884.1082150570.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document 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, 16 Apr 2004 14:22:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, It would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 08:09:52 -0700 From: Yakov Rekhter To: idr@ietf.org cc: skh@nexthop.com Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG documen t Folks, We receive a request to accept draft-lange-flexible-bgp-communities-02.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 28, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 16 17:56:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12675 for ; Fri, 16 Apr 2004 17:56: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 1BEb9M-0003li-Tw for idr-archive@odin.ietf.org; Fri, 16 Apr 2004 17:45:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GLjSbe014486 for idr-archive@odin.ietf.org; Fri, 16 Apr 2004 17:45:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEb2Y-0001jO-O0 for idr-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:38:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11933 for ; Fri, 16 Apr 2004 17:38:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEb2W-0003j2-3q for idr-web-archive@ietf.org; Fri, 16 Apr 2004 17:38:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEb1X-0003gO-00 for idr-web-archive@ietf.org; Fri, 16 Apr 2004 17:37:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEb0Y-0003ch-00; Fri, 16 Apr 2004 17:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxK-0008QB-4l; Fri, 16 Apr 2004 17:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEao0-0005qb-RY for idr@optimus.ietf.org; Fri, 16 Apr 2004 17:23: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 RAA11133 for ; Fri, 16 Apr 2004 17:23:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEany-0002uo-JO for idr@ietf.org; Fri, 16 Apr 2004 17:23:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEan4-0002tI-00 for idr@ietf.org; Fri, 16 Apr 2004 17:22:27 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEamS-0002pR-00 for idr@ietf.org; Fri, 16 Apr 2004 17:21:48 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3GLLIl98120 for ; Fri, 16 Apr 2004 14:21:18 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3GLLDJ87448 for ; Fri, 16 Apr 2004 14:21:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404162121.i3GLLDJ87448@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72719.1082150473.1@juniper.net> From: Yakov Rekhter Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-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, 16 Apr 2004 14:21:13 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, During the Last Call it would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 13:36:09 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. - ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - - --OtherAccess-- - - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 16 17:59:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12793 for ; Fri, 16 Apr 2004 17:59: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 1BEbG3-0005Fs-QY for idr-archive@odin.ietf.org; Fri, 16 Apr 2004 17:52:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GLqNkA020196 for idr-archive@odin.ietf.org; Fri, 16 Apr 2004 17:52:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEb6p-0003At-IZ for idr-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:42: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 RAA12136 for ; Fri, 16 Apr 2004 17:42:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEb6n-0003yR-20 for idr-web-archive@ietf.org; Fri, 16 Apr 2004 17:42:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEb5p-0003ux-00 for idr-web-archive@ietf.org; Fri, 16 Apr 2004 17:41:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEb5G-0003pe-00; Fri, 16 Apr 2004 17:41:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxL-0008Se-1P; Fri, 16 Apr 2004 17:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEapt-0006CJ-53 for idr@optimus.ietf.org; Fri, 16 Apr 2004 17:25:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11153 for ; Fri, 16 Apr 2004 17:25:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEapq-0002xN-OV for idr@ietf.org; Fri, 16 Apr 2004 17:25:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaos-0002vu-00 for idr@ietf.org; Fri, 16 Apr 2004 17:24:19 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEao1-0002u2-00 for idr@ietf.org; Fri, 16 Apr 2004 17:23:25 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3GLMtl98124 for ; Fri, 16 Apr 2004 14:22:55 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3GLMoJ87986 for ; Fri, 16 Apr 2004 14:22:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404162122.i3GLMoJ87986@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72884.1082150570.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document 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, 16 Apr 2004 14:22:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, It would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 08:09:52 -0700 From: Yakov Rekhter To: idr@ietf.org cc: skh@nexthop.com Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG documen t Folks, We receive a request to accept draft-lange-flexible-bgp-communities-02.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 28, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 19 14:03:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28167 for ; Mon, 19 Apr 2004 14:03:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFd79-00021J-Am for idr-archive@ietf.org; Mon, 19 Apr 2004 14:03:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFd6A-0001lW-00 for idr-archive@ietf.org; Mon, 19 Apr 2004 14:02:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFd5M-0001X2-00; Mon, 19 Apr 2004 14: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 1BFd0v-00020J-H5; Mon, 19 Apr 2004 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESUw-0007BM-RY for idr@optimus.ietf.org; Fri, 16 Apr 2004 08:31: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 IAA04053 for ; Fri, 16 Apr 2004 08:31:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BESUv-0006kz-KO for idr@ietf.org; Fri, 16 Apr 2004 08:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESTx-0006dc-00 for idr@ietf.org; Fri, 16 Apr 2004 08:30:10 -0400 Received: from aismtp1g.bellsouth.com ([139.76.165.196]) by ietf-mx with esmtp (Exim 4.12) id 1BEST1-0006Q7-00 for idr@ietf.org; Fri, 16 Apr 2004 08:29:11 -0400 Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP for idr@ietf.org; Fri, 16 Apr 2004 08:28:41 -0400 content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Priority: normal Importance: normal Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423AE.569985C0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: Thread-Topic: Peer Prefix Limits Exchange in BGP Thread-Index: AcQjrlagAp0P6YTmTHu8aoJkedLcdA== From: "Miri, Mohammad" To: Subject: [Idr] Peer Prefix Limits Exchange in BGP 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, 16 Apr 2004 07:28:35 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C423AE.569985C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Title : Peer Prefix Limits Exchange in BGP=20 Author(s) : V. Radoaca, et al.=20 Filename : draft-chavali-bgp-prefixlimit-01.txt=20 Pages : 14=20 Date : 2004-4-12=20 I would like to request this this draft becoming a working group draft. = Discussion during IETF=20 58, indicated there was interest from service providers to having this = become a working group=20 draft.=20 ***** "The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination = or other use of, or taking of any action in reliance upon, this = information by persons or entities other than the intended recipient is = prohibited. If you received this in error, please contact the sender = and delete the material from all computers." 113 ------_=_NextPart_001_01C423AE.569985C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peer Prefix Limits Exchange in BGP

        = Title           : Peer = Prefix Limits Exchange in BGP

        = Author(s)       : V. Radoaca, et al. =

        = Filename        : = draft-chavali-bgp-prefixlimit-01.txt

        = Pages           : 14 =

        = Date            : = 2004-4-12

I would like to request this this draft becoming a = working group draft.  Discussion during IETF

58, indicated there was interest from service = providers to having this become a working group

draft.

*****

"The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon, this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers." 113

 ------_=_NextPart_001_01C423AE.569985C0-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 19 14:04:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28301 for ; Mon, 19 Apr 2004 14:04:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFd7z-0002G1-Kp for idr-archive@ietf.org; Mon, 19 Apr 2004 14:04:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFd74-00020c-00 for idr-archive@ietf.org; Mon, 19 Apr 2004 14:03:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFd62-0001kR-00; Mon, 19 Apr 2004 14:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFd0w-00020R-0i; Mon, 19 Apr 2004 13:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcE7-0005Rm-33 for idr@optimus.ietf.org; Fri, 16 Apr 2004 18:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17600 for ; Fri, 16 Apr 2004 18:54:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEcE3-0000eL-ST for idr@ietf.org; Fri, 16 Apr 2004 18:54:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcD3-0000Zp-00 for idr@ietf.org; Fri, 16 Apr 2004 18:53:21 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BEcC4-0000VT-00 for idr@ietf.org; Fri, 16 Apr 2004 18:52:20 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3GMpn7X007020; Fri, 16 Apr 2004 18:51:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404142038.i3EKcHJ88016@merlot.juniper.net> References: <200404142038.i3EKcHJ88016@merlot.juniper.net> To: Yakov Rekhter From: Stephen Kent Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt Cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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, 16 Apr 2004 18:50:54 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 1:38 PM -0700 4/14/04, Yakov Rekhter wrote: >Steve, > >> > >> > >> > >> >Steve, would you mind making a suggestion on how the text could >>be improved? >> >E.g., would a separate section in the main body of the document specifying >> >the requirement for TCP-MD5 support be useful? >> >> A reasonable approach would be to have a section of the document that >> describes the use of this TCP option. It should explain why/when one >> would use the option in the context of BGP links and what protection >> it offers. > >Would you please produce the appropriate text for this section. > >Thanks in advance. > >Yakov. I'll try to provide some text when I return from vacation, in early May. Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 19 14:14:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28917 for ; Mon, 19 Apr 2004 14:14: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 1BFdFW-0005FE-6I for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 14:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JIC6GU020160 for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 14:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFd7D-0003Az-Fv for idr-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 14:03: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 OAA28197 for ; Mon, 19 Apr 2004 14:03:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFd7B-00021U-2A for idr-web-archive@ietf.org; Mon, 19 Apr 2004 14:03:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFd6C-0001ln-00 for idr-web-archive@ietf.org; Mon, 19 Apr 2004 14:02:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFd5M-0001X2-00; Mon, 19 Apr 2004 14: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 1BFd0v-00020J-H5; Mon, 19 Apr 2004 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESUw-0007BM-RY for idr@optimus.ietf.org; Fri, 16 Apr 2004 08:31: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 IAA04053 for ; Fri, 16 Apr 2004 08:31:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BESUv-0006kz-KO for idr@ietf.org; Fri, 16 Apr 2004 08:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESTx-0006dc-00 for idr@ietf.org; Fri, 16 Apr 2004 08:30:10 -0400 Received: from aismtp1g.bellsouth.com ([139.76.165.196]) by ietf-mx with esmtp (Exim 4.12) id 1BEST1-0006Q7-00 for idr@ietf.org; Fri, 16 Apr 2004 08:29:11 -0400 Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP for idr@ietf.org; Fri, 16 Apr 2004 08:28:41 -0400 content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Priority: normal Importance: normal Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423AE.569985C0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: Thread-Topic: Peer Prefix Limits Exchange in BGP Thread-Index: AcQjrlagAp0P6YTmTHu8aoJkedLcdA== From: "Miri, Mohammad" To: Subject: [Idr] Peer Prefix Limits Exchange in BGP 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, 16 Apr 2004 07:28:35 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C423AE.569985C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Title : Peer Prefix Limits Exchange in BGP=20 Author(s) : V. Radoaca, et al.=20 Filename : draft-chavali-bgp-prefixlimit-01.txt=20 Pages : 14=20 Date : 2004-4-12=20 I would like to request this this draft becoming a working group draft. = Discussion during IETF=20 58, indicated there was interest from service providers to having this = become a working group=20 draft.=20 ***** "The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination = or other use of, or taking of any action in reliance upon, this = information by persons or entities other than the intended recipient is = prohibited. If you received this in error, please contact the sender = and delete the material from all computers." 113 ------_=_NextPart_001_01C423AE.569985C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peer Prefix Limits Exchange in BGP

        = Title           : Peer = Prefix Limits Exchange in BGP

        = Author(s)       : V. Radoaca, et al. =

        = Filename        : = draft-chavali-bgp-prefixlimit-01.txt

        = Pages           : 14 =

        = Date            : = 2004-4-12

I would like to request this this draft becoming a = working group draft.  Discussion during IETF

58, indicated there was interest from service = providers to having this become a working group

draft.

*****

"The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon, this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers." 113

 ------_=_NextPart_001_01C423AE.569985C0-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 19 14:14:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28983 for ; Mon, 19 Apr 2004 14:14:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdFW-0005Fq-VO for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 14:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JIC61R020194 for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 14:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFd83-0003VC-El for idr-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 14:04:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28327 for ; Mon, 19 Apr 2004 14:04:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFd80-0002GC-Vh for idr-web-archive@ietf.org; Mon, 19 Apr 2004 14:04:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFd75-00020q-00 for idr-web-archive@ietf.org; Mon, 19 Apr 2004 14:03:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFd62-0001kR-00; Mon, 19 Apr 2004 14:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFd0w-00020R-0i; Mon, 19 Apr 2004 13:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcE7-0005Rm-33 for idr@optimus.ietf.org; Fri, 16 Apr 2004 18:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17600 for ; Fri, 16 Apr 2004 18:54:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEcE3-0000eL-ST for idr@ietf.org; Fri, 16 Apr 2004 18:54:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcD3-0000Zp-00 for idr@ietf.org; Fri, 16 Apr 2004 18:53:21 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BEcC4-0000VT-00 for idr@ietf.org; Fri, 16 Apr 2004 18:52:20 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3GMpn7X007020; Fri, 16 Apr 2004 18:51:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404142038.i3EKcHJ88016@merlot.juniper.net> References: <200404142038.i3EKcHJ88016@merlot.juniper.net> To: Yakov Rekhter From: Stephen Kent Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt Cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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, 16 Apr 2004 18:50:54 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 1:38 PM -0700 4/14/04, Yakov Rekhter wrote: >Steve, > >> > >> > >> > >> >Steve, would you mind making a suggestion on how the text could >>be improved? >> >E.g., would a separate section in the main body of the document specifying >> >the requirement for TCP-MD5 support be useful? >> >> A reasonable approach would be to have a section of the document that >> describes the use of this TCP option. It should explain why/when one >> would use the option in the context of BGP links and what protection >> it offers. > >Would you please produce the appropriate text for this section. > >Thanks in advance. > >Yakov. I'll try to provide some text when I return from vacation, in early May. Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 19 16:26:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07611 for ; Mon, 19 Apr 2004 16:26:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfLK-0005s8-8L for idr-archive@ietf.org; Mon, 19 Apr 2004 16:26:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfKK-0005bB-00 for idr-archive@ietf.org; Mon, 19 Apr 2004 16:25:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfJI-00059K-00; Mon, 19 Apr 2004 16:24:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf8j-0003Xn-OA; Mon, 19 Apr 2004 16:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf3y-0002Rt-DT for idr@optimus.ietf.org; Mon, 19 Apr 2004 16:08:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06535 for ; Mon, 19 Apr 2004 16:08:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFf3w-0001HS-IE for idr@ietf.org; Mon, 19 Apr 2004 16:08:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFf34-00014Z-00 for idr@ietf.org; Mon, 19 Apr 2004 16:07:23 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFf2Z-0000qr-00 for idr@ietf.org; Mon, 19 Apr 2004 16:06:51 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFf2Z-000Jyr-Nj for idr@ietf.org; Mon, 19 Apr 2004 20:06:51 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <107409968.20040419130650@psg.com> To: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Mon, 19 Apr 2004 13:06:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- I've received some more comments on this document included below. Please take them into consideration. Thanks. -- Alex http://www.psg.com/~zinin/ >> # NLRI Mean AS Distance # AS's Bandwidth (MR) ^ ^ ^ ^ N M A BW >> ---------- ---------------- ------ ---------------- >> 40,000 15 400 184,000 bytes >> 100,000 10 10,000 800,000 bytes >> 120,000 10 15,000 1,080,000 bytes >> 140,000 15 20,000 1,760,000 bytes >> >> [note that most of this bandwidth is consumed by the NLRI exchange] > > Is the caption for column 3 correct? It says "# AS's", which reads as > "number of AS's" while it seems it should be the number of unique paths. The text is clear; but your caption would be better. At least here the arithmetic is right. BTW, the caption for column 4 is also wrong. "MR" hasn't been introduced yet. >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The > > While theoretically the text is correct and we could talk about periods > of stability and instability of the Internet, I wonder if this text is > still applicable from the practical perspective. I.e., the continuous > churn that the Internet BGP speakers experience ensures that they > practically always have something to process. Agreed: this is as "stable" as we're going to get; we shouldn't call it "instability". > Probably instead of talking about periods of "Internet stability" and > "Internet instability" we could talk about something like "periods of > stable state among BGP speakers when they do no have new updates to > communicate to each other". That's accurate; but I wonder whether it's worth talking about. > Not sure I follow here. What is meant by the "steady state" here? If it > means convergence on a stable topology after the initial exchange of > updates, then why talk about "stability of the Internet"? I took this to mean that whenever a BGP session starts, there's a potentially long initial exchange of routes, and we mean to exclude that startup transient. But, of course, we're back to the "stable Internet" paradigm. :^( > In other words, if the Internet is unstable then can we say that the > BGP speakers are in steady state? We can, but it's kind of confusing. I believe the intent was to have a "slightly unstable" Internet causing CPU load which doesn't become visible until we get past the startup transient. > In the lack of topology changes, it seems that the consumption should > instead depend on the number of peers (affects KEEPALIVE processing) > and the number of persistently oscillating routes potentially present > in the network... I'd rather talk in those terms; but it's a rather major rewrite of this section. >> This assumes >> that as the Internet grows, the overall stability of the inter-AS >> connectivity of the Internet can be controlled. > > please specify how it is assumed to be "controlled", e.g. through operational > practices. I believe historically this meant route-flap damping. >> In particular, while >> the size of the IPv4 Internet routing table is bounded by O(232 * M), > > 232 or 2^32? Neither makes much sense. Usually one would simply say O(M). >> (where M is a slow-moving function describing the AS >> interconnectivity of the network), > > slow-moving or slow-growing? I believe "slow-moving" is correct -- especially as compared to the speed of the arm-waving inherent in this sentence. ;^) >> no such bound can be formulated >> for the dynamic properties (i.e., stability) of BGP. There's the "stability" word again. :^( >> Although, the >> dynamic properties of the network cannot be quantitatively bounded, >> they can be controlled within BGP. Beyond certain changes in the >> network, BGP can start to suppress such changes using BGP Route Flap >> Damping [RFC2439], pacing of its route updates, or BGP would be >> unable to keep up with the changes and force suppression of multiple >> changes over very short periods by causing the BGP peer socket to >> block on the sender. The arms are waving again. We list methods of suppressing _some_ multiple changes and claim this avoids suppression of multiple changes. (This sentence would be quite correct if we said "force suppression of _all_ changes...") >> 6.1.2. Memory requirements >> >> To quantify the worst case memory requirements for BGP, we denote the >> total number of networks in the Internet by N, the mean AS distance >> of the Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths as A. Then the worst case memory >> requirements (MR) can be expressed as >> >> MR = O(N + (M * A)) >> >> Since a mean AS distance M is a slow moving function of the >> interconnectivity ("meshiness") of the Internet, for all practical >> purposes the worst case router memory requirements are on the order >> of the total number of networks in the Internet times the number of >> peers the local system is peering with. We expect that the total >> number of networks in the Internet will grow much faster than the >> average number of peers per router. As a result, BGP's memory >> scaling properties are linearly related to the total number of >> networks in the Internet. >> >> The following table illustrates typical memory requirements of a >> router running BGP. We denote average number of routes advertised by >> each peer as N, the total number of unique AS paths as A, the mean AS >> distance of the Internet as M (distance at the level of an autonomous >> system, expressed in terms of the number of autonomous systems), >> number of bytes required to store a route as R, and number of bytes >> required to store one AS in an AS path as P. It is assumed that each >> network is encoded as four bytes, each AS is encoded as two bytes, >> and each networks is reachable via some fraction of all of the peers >> (# BGP peers/per net). For purposes of the estimates here, we will >> calculate MR = ((N * R) + (M * A) * P) One is forced to guess that R = 4. I think the intent was that P is two times the BGP-peers column. >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) ^ ^ ^ ^ ^ N M A P (???) MR >> ---------- ---------------- ------ ------------------- -------------- >> 100,000 20 3,000 20 1,040,000 >> 100,000 20 15,000 20 1,040,000 >> 120,000 10 15,000 100 75,000,000 >> 140,000 15 20,000 100 116,000,000 Well, to tell truth, I've forgotten how I reproduced two of those MR numbers. But it's certainly obvious they can't all be right; and today I can't reproduce a single one of them. >> In analyzing BGP's memory requirements, we focus on the size of the >> forwarding table (and ignoring implementation details). In >> particular, we derive upper bounds for the size of the forwarding >> table. > > The above doesn't look like calculations for a forwarding table--the > FIB doesn't normally contact AS-PATH info or all possible paths to a > destination. Agreed. I didn't think that was a FIB calculation -- though I never was sure what it was... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 19 16:41:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08586 for ; Mon, 19 Apr 2004 16:41: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 1BFfRq-00089q-Qs for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 16:32:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JKWwP3031354 for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 16:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfLO-0006iT-S9 for idr-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 16:26:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07637 for ; Mon, 19 Apr 2004 16:26:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfLN-0005sZ-2U for idr-web-archive@ietf.org; Mon, 19 Apr 2004 16:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfKM-0005bS-00 for idr-web-archive@ietf.org; Mon, 19 Apr 2004 16:25:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfJI-00059K-00; Mon, 19 Apr 2004 16:24:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf8j-0003Xn-OA; Mon, 19 Apr 2004 16:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf3y-0002Rt-DT for idr@optimus.ietf.org; Mon, 19 Apr 2004 16:08:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06535 for ; Mon, 19 Apr 2004 16:08:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFf3w-0001HS-IE for idr@ietf.org; Mon, 19 Apr 2004 16:08:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFf34-00014Z-00 for idr@ietf.org; Mon, 19 Apr 2004 16:07:23 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFf2Z-0000qr-00 for idr@ietf.org; Mon, 19 Apr 2004 16:06:51 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFf2Z-000Jyr-Nj for idr@ietf.org; Mon, 19 Apr 2004 20:06:51 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <107409968.20040419130650@psg.com> To: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Mon, 19 Apr 2004 13:06:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- I've received some more comments on this document included below. Please take them into consideration. Thanks. -- Alex http://www.psg.com/~zinin/ >> # NLRI Mean AS Distance # AS's Bandwidth (MR) ^ ^ ^ ^ N M A BW >> ---------- ---------------- ------ ---------------- >> 40,000 15 400 184,000 bytes >> 100,000 10 10,000 800,000 bytes >> 120,000 10 15,000 1,080,000 bytes >> 140,000 15 20,000 1,760,000 bytes >> >> [note that most of this bandwidth is consumed by the NLRI exchange] > > Is the caption for column 3 correct? It says "# AS's", which reads as > "number of AS's" while it seems it should be the number of unique paths. The text is clear; but your caption would be better. At least here the arithmetic is right. BTW, the caption for column 4 is also wrong. "MR" hasn't been introduced yet. >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The > > While theoretically the text is correct and we could talk about periods > of stability and instability of the Internet, I wonder if this text is > still applicable from the practical perspective. I.e., the continuous > churn that the Internet BGP speakers experience ensures that they > practically always have something to process. Agreed: this is as "stable" as we're going to get; we shouldn't call it "instability". > Probably instead of talking about periods of "Internet stability" and > "Internet instability" we could talk about something like "periods of > stable state among BGP speakers when they do no have new updates to > communicate to each other". That's accurate; but I wonder whether it's worth talking about. > Not sure I follow here. What is meant by the "steady state" here? If it > means convergence on a stable topology after the initial exchange of > updates, then why talk about "stability of the Internet"? I took this to mean that whenever a BGP session starts, there's a potentially long initial exchange of routes, and we mean to exclude that startup transient. But, of course, we're back to the "stable Internet" paradigm. :^( > In other words, if the Internet is unstable then can we say that the > BGP speakers are in steady state? We can, but it's kind of confusing. I believe the intent was to have a "slightly unstable" Internet causing CPU load which doesn't become visible until we get past the startup transient. > In the lack of topology changes, it seems that the consumption should > instead depend on the number of peers (affects KEEPALIVE processing) > and the number of persistently oscillating routes potentially present > in the network... I'd rather talk in those terms; but it's a rather major rewrite of this section. >> This assumes >> that as the Internet grows, the overall stability of the inter-AS >> connectivity of the Internet can be controlled. > > please specify how it is assumed to be "controlled", e.g. through operational > practices. I believe historically this meant route-flap damping. >> In particular, while >> the size of the IPv4 Internet routing table is bounded by O(232 * M), > > 232 or 2^32? Neither makes much sense. Usually one would simply say O(M). >> (where M is a slow-moving function describing the AS >> interconnectivity of the network), > > slow-moving or slow-growing? I believe "slow-moving" is correct -- especially as compared to the speed of the arm-waving inherent in this sentence. ;^) >> no such bound can be formulated >> for the dynamic properties (i.e., stability) of BGP. There's the "stability" word again. :^( >> Although, the >> dynamic properties of the network cannot be quantitatively bounded, >> they can be controlled within BGP. Beyond certain changes in the >> network, BGP can start to suppress such changes using BGP Route Flap >> Damping [RFC2439], pacing of its route updates, or BGP would be >> unable to keep up with the changes and force suppression of multiple >> changes over very short periods by causing the BGP peer socket to >> block on the sender. The arms are waving again. We list methods of suppressing _some_ multiple changes and claim this avoids suppression of multiple changes. (This sentence would be quite correct if we said "force suppression of _all_ changes...") >> 6.1.2. Memory requirements >> >> To quantify the worst case memory requirements for BGP, we denote the >> total number of networks in the Internet by N, the mean AS distance >> of the Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths as A. Then the worst case memory >> requirements (MR) can be expressed as >> >> MR = O(N + (M * A)) >> >> Since a mean AS distance M is a slow moving function of the >> interconnectivity ("meshiness") of the Internet, for all practical >> purposes the worst case router memory requirements are on the order >> of the total number of networks in the Internet times the number of >> peers the local system is peering with. We expect that the total >> number of networks in the Internet will grow much faster than the >> average number of peers per router. As a result, BGP's memory >> scaling properties are linearly related to the total number of >> networks in the Internet. >> >> The following table illustrates typical memory requirements of a >> router running BGP. We denote average number of routes advertised by >> each peer as N, the total number of unique AS paths as A, the mean AS >> distance of the Internet as M (distance at the level of an autonomous >> system, expressed in terms of the number of autonomous systems), >> number of bytes required to store a route as R, and number of bytes >> required to store one AS in an AS path as P. It is assumed that each >> network is encoded as four bytes, each AS is encoded as two bytes, >> and each networks is reachable via some fraction of all of the peers >> (# BGP peers/per net). For purposes of the estimates here, we will >> calculate MR = ((N * R) + (M * A) * P) One is forced to guess that R = 4. I think the intent was that P is two times the BGP-peers column. >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) ^ ^ ^ ^ ^ N M A P (???) MR >> ---------- ---------------- ------ ------------------- -------------- >> 100,000 20 3,000 20 1,040,000 >> 100,000 20 15,000 20 1,040,000 >> 120,000 10 15,000 100 75,000,000 >> 140,000 15 20,000 100 116,000,000 Well, to tell truth, I've forgotten how I reproduced two of those MR numbers. But it's certainly obvious they can't all be right; and today I can't reproduce a single one of them. >> In analyzing BGP's memory requirements, we focus on the size of the >> forwarding table (and ignoring implementation details). In >> particular, we derive upper bounds for the size of the forwarding >> table. > > The above doesn't look like calculations for a forwarding table--the > FIB doesn't normally contact AS-PATH info or all possible paths to a > destination. Agreed. I didn't think that was a FIB calculation -- though I never was sure what it was... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 19 16:56:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09615 for ; Mon, 19 Apr 2004 16:56:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfoP-0005cc-DS for idr-archive@ietf.org; Mon, 19 Apr 2004 16:56:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfnP-0005Md-00 for idr-archive@ietf.org; Mon, 19 Apr 2004 16:55:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfmV-00056i-00; Mon, 19 Apr 2004 16:54:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfae-00023j-AY; Mon, 19 Apr 2004 16:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfV1-0000LV-Aj for idr@optimus.ietf.org; Mon, 19 Apr 2004 16:36:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08336 for ; Mon, 19 Apr 2004 16:36:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfUz-0000YZ-CT for idr@ietf.org; Mon, 19 Apr 2004 16:36:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfU2-0000Kb-00 for idr@ietf.org; Mon, 19 Apr 2004 16:35:15 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BFfT4-0007fh-00 for idr@ietf.org; Mon, 19 Apr 2004 16:34:14 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3JKXirS015123; Mon, 19 Apr 2004 13:33:44 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3JKXive015122; Mon, 19 Apr 2004 13:33:44 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f From: David Meyer To: Alex Zinin Cc: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Message-ID: <20040419203344.GA15050@1-4-5.net> References: <107409968.20040419130650@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <107409968.20040419130650@psg.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon 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, 19 Apr 2004 13:33:44 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 All, Thanks for the comments. We're working on the update as we speak. BTW, wrt this: >> >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> > >> > 232 or 2^32? >> >> Neither makes much sense. Usually one would simply say O(M). >> >> >> (where M is a slow-moving function describing the AS >> >> interconnectivity of the network), >> > >> > slow-moving or slow-growing? >> >> I believe "slow-moving" is correct -- especially as compared to the >> speed of the arm-waving inherent in this sentence. ;^) what I was trying to get at is that the size of the RIB is going to be bounded by something like 2^32 *, where the represents the AS-meshiness, which (in practice) doesn't change at a very large rate. So O(M) is incorrect. The basic idea was to (attempt to) contrast the size of the RIB with its dynamic properties. So do people disagree that the size of the RIB is bounded in this way? Thanks, Dave >> I've received some more comments on this document included below. >> Please take them into consideration. >> >> Thanks. >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> >> # NLRI Mean AS Distance # AS's Bandwidth (MR) >> ^ ^ ^ ^ >> N M A BW >> >> ---------- ---------------- ------ ---------------- >> >> 40,000 15 400 184,000 bytes >> >> 100,000 10 10,000 800,000 bytes >> >> 120,000 10 15,000 1,080,000 bytes >> >> 140,000 15 20,000 1,760,000 bytes >> >> >> >> [note that most of this bandwidth is consumed by the NLRI exchange] >> > >> > Is the caption for column 3 correct? It says "# AS's", which reads as >> > "number of AS's" while it seems it should be the number of unique paths. >> >> The text is clear; but your caption would be better. >> >> At least here the arithmetic is right. >> >> BTW, the caption for column 4 is also wrong. "MR" hasn't been >> introduced yet. >> >> >> During periods of Internet instability, changes to the reachability >> >> information are passed between routers in UPDATE messages. The >> > >> > While theoretically the text is correct and we could talk about periods >> > of stability and instability of the Internet, I wonder if this text is >> > still applicable from the practical perspective. I.e., the continuous >> > churn that the Internet BGP speakers experience ensures that they >> > practically always have something to process. >> >> Agreed: this is as "stable" as we're going to get; we shouldn't call >> it "instability". >> >> > Probably instead of talking about periods of "Internet stability" and >> > "Internet instability" we could talk about something like "periods of >> > stable state among BGP speakers when they do no have new updates to >> > communicate to each other". >> >> That's accurate; but I wonder whether it's worth talking about. >> >> > Not sure I follow here. What is meant by the "steady state" here? If it >> > means convergence on a stable topology after the initial exchange of >> > updates, then why talk about "stability of the Internet"? >> >> I took this to mean that whenever a BGP session starts, there's a >> potentially long initial exchange of routes, and we mean to exclude >> that startup transient. >> >> But, of course, we're back to the "stable Internet" paradigm. :^( >> >> > In other words, if the Internet is unstable then can we say that the >> > BGP speakers are in steady state? >> >> We can, but it's kind of confusing. I believe the intent was to >> have a "slightly unstable" Internet causing CPU load which doesn't >> become visible until we get past the startup transient. >> >> > In the lack of topology changes, it seems that the consumption should >> > instead depend on the number of peers (affects KEEPALIVE processing) >> > and the number of persistently oscillating routes potentially present >> > in the network... >> >> I'd rather talk in those terms; but it's a rather major rewrite of >> this section. >> >> >> This assumes >> >> that as the Internet grows, the overall stability of the inter-AS >> >> connectivity of the Internet can be controlled. >> > >> > please specify how it is assumed to be "controlled", e.g. through operational >> > practices. >> >> I believe historically this meant route-flap damping. >> >> >> In particular, while >> >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> > >> > 232 or 2^32? >> >> Neither makes much sense. Usually one would simply say O(M). >> >> >> (where M is a slow-moving function describing the AS >> >> interconnectivity of the network), >> > >> > slow-moving or slow-growing? >> >> I believe "slow-moving" is correct -- especially as compared to the >> speed of the arm-waving inherent in this sentence. ;^) >> >> >> no such bound can be formulated >> >> for the dynamic properties (i.e., stability) of BGP. >> >> There's the "stability" word again. :^( >> >> >> Although, the >> >> dynamic properties of the network cannot be quantitatively bounded, >> >> they can be controlled within BGP. Beyond certain changes in the >> >> network, BGP can start to suppress such changes using BGP Route Flap >> >> Damping [RFC2439], pacing of its route updates, or BGP would be >> >> unable to keep up with the changes and force suppression of multiple >> >> changes over very short periods by causing the BGP peer socket to >> >> block on the sender. >> >> The arms are waving again. We list methods of suppressing _some_ >> multiple changes and claim this avoids suppression of multiple changes. >> (This sentence would be quite correct if we said "force suppression of >> _all_ changes...") >> >> >> 6.1.2. Memory requirements >> >> >> >> To quantify the worst case memory requirements for BGP, we denote the >> >> total number of networks in the Internet by N, the mean AS distance >> >> of the Internet by M (distance at the level of an autonomous system, >> >> expressed in terms of the number of autonomous systems), the total >> >> number of unique AS paths as A. Then the worst case memory >> >> requirements (MR) can be expressed as >> >> >> >> MR = O(N + (M * A)) >> >> >> >> Since a mean AS distance M is a slow moving function of the >> >> interconnectivity ("meshiness") of the Internet, for all practical >> >> purposes the worst case router memory requirements are on the order >> >> of the total number of networks in the Internet times the number of >> >> peers the local system is peering with. We expect that the total >> >> number of networks in the Internet will grow much faster than the >> >> average number of peers per router. As a result, BGP's memory >> >> scaling properties are linearly related to the total number of >> >> networks in the Internet. >> >> >> >> The following table illustrates typical memory requirements of a >> >> router running BGP. We denote average number of routes advertised by >> >> each peer as N, the total number of unique AS paths as A, the mean AS >> >> distance of the Internet as M (distance at the level of an autonomous >> >> system, expressed in terms of the number of autonomous systems), >> >> number of bytes required to store a route as R, and number of bytes >> >> required to store one AS in an AS path as P. It is assumed that each >> >> network is encoded as four bytes, each AS is encoded as two bytes, >> >> and each networks is reachable via some fraction of all of the peers >> >> (# BGP peers/per net). For purposes of the estimates here, we will >> >> calculate MR = ((N * R) + (M * A) * P) >> >> One is forced to guess that R = 4. >> >> I think the intent was that P is two times the BGP-peers column. >> >> >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) >> ^ ^ ^ ^ ^ >> N M A P (???) MR >> >> ---------- ---------------- ------ ------------------- -------------- >> >> 100,000 20 3,000 20 1,040,000 >> >> 100,000 20 15,000 20 1,040,000 >> >> 120,000 10 15,000 100 75,000,000 >> >> 140,000 15 20,000 100 116,000,000 >> >> Well, to tell truth, I've forgotten how I reproduced two of those MR >> numbers. But it's certainly obvious they can't all be right; and today I >> can't reproduce a single one of them. >> >> >> In analyzing BGP's memory requirements, we focus on the size of the >> >> forwarding table (and ignoring implementation details). In >> >> particular, we derive upper bounds for the size of the forwarding >> >> table. >> > >> > The above doesn't look like calculations for a forwarding table--the >> > FIB doesn't normally contact AS-PATH info or all possible paths to a >> > destination. >> >> Agreed. I didn't think that was a FIB calculation -- though I never >> was sure what it was... >> >> >> >> _______________________________________________ >> 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 Mon Apr 19 17:15:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10668 for ; Mon, 19 Apr 2004 17:15:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfsA-0005kL-L8 for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 17:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JL0A28022084 for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 17:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfoT-0004LY-1Q for idr-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 16:56:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09641 for ; Mon, 19 Apr 2004 16:56:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfoQ-0005cm-RO for idr-web-archive@ietf.org; Mon, 19 Apr 2004 16:56:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfnS-0005Mr-00 for idr-web-archive@ietf.org; Mon, 19 Apr 2004 16:55:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfmV-00056i-00; Mon, 19 Apr 2004 16:54:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfae-00023j-AY; Mon, 19 Apr 2004 16:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfV1-0000LV-Aj for idr@optimus.ietf.org; Mon, 19 Apr 2004 16:36:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08336 for ; Mon, 19 Apr 2004 16:36:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfUz-0000YZ-CT for idr@ietf.org; Mon, 19 Apr 2004 16:36:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfU2-0000Kb-00 for idr@ietf.org; Mon, 19 Apr 2004 16:35:15 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BFfT4-0007fh-00 for idr@ietf.org; Mon, 19 Apr 2004 16:34:14 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3JKXirS015123; Mon, 19 Apr 2004 13:33:44 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3JKXive015122; Mon, 19 Apr 2004 13:33:44 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f From: David Meyer To: Alex Zinin Cc: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Message-ID: <20040419203344.GA15050@1-4-5.net> References: <107409968.20040419130650@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <107409968.20040419130650@psg.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon 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, 19 Apr 2004 13:33:44 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 All, Thanks for the comments. We're working on the update as we speak. BTW, wrt this: >> >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> > >> > 232 or 2^32? >> >> Neither makes much sense. Usually one would simply say O(M). >> >> >> (where M is a slow-moving function describing the AS >> >> interconnectivity of the network), >> > >> > slow-moving or slow-growing? >> >> I believe "slow-moving" is correct -- especially as compared to the >> speed of the arm-waving inherent in this sentence. ;^) what I was trying to get at is that the size of the RIB is going to be bounded by something like 2^32 *, where the represents the AS-meshiness, which (in practice) doesn't change at a very large rate. So O(M) is incorrect. The basic idea was to (attempt to) contrast the size of the RIB with its dynamic properties. So do people disagree that the size of the RIB is bounded in this way? Thanks, Dave >> I've received some more comments on this document included below. >> Please take them into consideration. >> >> Thanks. >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> >> # NLRI Mean AS Distance # AS's Bandwidth (MR) >> ^ ^ ^ ^ >> N M A BW >> >> ---------- ---------------- ------ ---------------- >> >> 40,000 15 400 184,000 bytes >> >> 100,000 10 10,000 800,000 bytes >> >> 120,000 10 15,000 1,080,000 bytes >> >> 140,000 15 20,000 1,760,000 bytes >> >> >> >> [note that most of this bandwidth is consumed by the NLRI exchange] >> > >> > Is the caption for column 3 correct? It says "# AS's", which reads as >> > "number of AS's" while it seems it should be the number of unique paths. >> >> The text is clear; but your caption would be better. >> >> At least here the arithmetic is right. >> >> BTW, the caption for column 4 is also wrong. "MR" hasn't been >> introduced yet. >> >> >> During periods of Internet instability, changes to the reachability >> >> information are passed between routers in UPDATE messages. The >> > >> > While theoretically the text is correct and we could talk about periods >> > of stability and instability of the Internet, I wonder if this text is >> > still applicable from the practical perspective. I.e., the continuous >> > churn that the Internet BGP speakers experience ensures that they >> > practically always have something to process. >> >> Agreed: this is as "stable" as we're going to get; we shouldn't call >> it "instability". >> >> > Probably instead of talking about periods of "Internet stability" and >> > "Internet instability" we could talk about something like "periods of >> > stable state among BGP speakers when they do no have new updates to >> > communicate to each other". >> >> That's accurate; but I wonder whether it's worth talking about. >> >> > Not sure I follow here. What is meant by the "steady state" here? If it >> > means convergence on a stable topology after the initial exchange of >> > updates, then why talk about "stability of the Internet"? >> >> I took this to mean that whenever a BGP session starts, there's a >> potentially long initial exchange of routes, and we mean to exclude >> that startup transient. >> >> But, of course, we're back to the "stable Internet" paradigm. :^( >> >> > In other words, if the Internet is unstable then can we say that the >> > BGP speakers are in steady state? >> >> We can, but it's kind of confusing. I believe the intent was to >> have a "slightly unstable" Internet causing CPU load which doesn't >> become visible until we get past the startup transient. >> >> > In the lack of topology changes, it seems that the consumption should >> > instead depend on the number of peers (affects KEEPALIVE processing) >> > and the number of persistently oscillating routes potentially present >> > in the network... >> >> I'd rather talk in those terms; but it's a rather major rewrite of >> this section. >> >> >> This assumes >> >> that as the Internet grows, the overall stability of the inter-AS >> >> connectivity of the Internet can be controlled. >> > >> > please specify how it is assumed to be "controlled", e.g. through operational >> > practices. >> >> I believe historically this meant route-flap damping. >> >> >> In particular, while >> >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> > >> > 232 or 2^32? >> >> Neither makes much sense. Usually one would simply say O(M). >> >> >> (where M is a slow-moving function describing the AS >> >> interconnectivity of the network), >> > >> > slow-moving or slow-growing? >> >> I believe "slow-moving" is correct -- especially as compared to the >> speed of the arm-waving inherent in this sentence. ;^) >> >> >> no such bound can be formulated >> >> for the dynamic properties (i.e., stability) of BGP. >> >> There's the "stability" word again. :^( >> >> >> Although, the >> >> dynamic properties of the network cannot be quantitatively bounded, >> >> they can be controlled within BGP. Beyond certain changes in the >> >> network, BGP can start to suppress such changes using BGP Route Flap >> >> Damping [RFC2439], pacing of its route updates, or BGP would be >> >> unable to keep up with the changes and force suppression of multiple >> >> changes over very short periods by causing the BGP peer socket to >> >> block on the sender. >> >> The arms are waving again. We list methods of suppressing _some_ >> multiple changes and claim this avoids suppression of multiple changes. >> (This sentence would be quite correct if we said "force suppression of >> _all_ changes...") >> >> >> 6.1.2. Memory requirements >> >> >> >> To quantify the worst case memory requirements for BGP, we denote the >> >> total number of networks in the Internet by N, the mean AS distance >> >> of the Internet by M (distance at the level of an autonomous system, >> >> expressed in terms of the number of autonomous systems), the total >> >> number of unique AS paths as A. Then the worst case memory >> >> requirements (MR) can be expressed as >> >> >> >> MR = O(N + (M * A)) >> >> >> >> Since a mean AS distance M is a slow moving function of the >> >> interconnectivity ("meshiness") of the Internet, for all practical >> >> purposes the worst case router memory requirements are on the order >> >> of the total number of networks in the Internet times the number of >> >> peers the local system is peering with. We expect that the total >> >> number of networks in the Internet will grow much faster than the >> >> average number of peers per router. As a result, BGP's memory >> >> scaling properties are linearly related to the total number of >> >> networks in the Internet. >> >> >> >> The following table illustrates typical memory requirements of a >> >> router running BGP. We denote average number of routes advertised by >> >> each peer as N, the total number of unique AS paths as A, the mean AS >> >> distance of the Internet as M (distance at the level of an autonomous >> >> system, expressed in terms of the number of autonomous systems), >> >> number of bytes required to store a route as R, and number of bytes >> >> required to store one AS in an AS path as P. It is assumed that each >> >> network is encoded as four bytes, each AS is encoded as two bytes, >> >> and each networks is reachable via some fraction of all of the peers >> >> (# BGP peers/per net). For purposes of the estimates here, we will >> >> calculate MR = ((N * R) + (M * A) * P) >> >> One is forced to guess that R = 4. >> >> I think the intent was that P is two times the BGP-peers column. >> >> >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) >> ^ ^ ^ ^ ^ >> N M A P (???) MR >> >> ---------- ---------------- ------ ------------------- -------------- >> >> 100,000 20 3,000 20 1,040,000 >> >> 100,000 20 15,000 20 1,040,000 >> >> 120,000 10 15,000 100 75,000,000 >> >> 140,000 15 20,000 100 116,000,000 >> >> Well, to tell truth, I've forgotten how I reproduced two of those MR >> numbers. But it's certainly obvious they can't all be right; and today I >> can't reproduce a single one of them. >> >> >> In analyzing BGP's memory requirements, we focus on the size of the >> >> forwarding table (and ignoring implementation details). In >> >> particular, we derive upper bounds for the size of the forwarding >> >> table. >> > >> > The above doesn't look like calculations for a forwarding table--the >> > FIB doesn't normally contact AS-PATH info or all possible paths to a >> > destination. >> >> Agreed. I didn't think that was a FIB calculation -- though I never >> was sure what it was... >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 19 18:15:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15578 for ; Mon, 19 Apr 2004 18:15:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFh2z-000271-JV for idr-archive@ietf.org; Mon, 19 Apr 2004 18:15:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFh1w-0001pr-00 for idr-archive@ietf.org; Mon, 19 Apr 2004 18:14:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFh0w-0001ZG-00; Mon, 19 Apr 2004 18:13:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgq4-0004Jj-Ey; Mon, 19 Apr 2004 18:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgk5-0001u6-2m for idr@optimus.ietf.org; Mon, 19 Apr 2004 17:55: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 RAA13373 for ; Mon, 19 Apr 2004 17:55:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgk2-0004jq-ET for idr@ietf.org; Mon, 19 Apr 2004 17:55:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFgj8-0004Sd-00 for idr@ietf.org; Mon, 19 Apr 2004 17:54:55 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFgiC-0004BA-00 for idr@ietf.org; Mon, 19 Apr 2004 17:53:56 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFgiB-000Myc-R7; Mon, 19 Apr 2004 21:53:55 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <616478494.20040419145355@psg.com> To: Pekka Savola CC: ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: References: <139156231539.20040319113030@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Mon, 19 Apr 2004 14:53:55 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka, [cc'ing IDR] Thanks for a careful follow-up. Inline below, pls. Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote: > On Fri, 19 Mar 2004, Alex Zinin wrote: >> Below is the IETF LC announcement that should have made it to several >> lists and hasn't yet >> >> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html > FWIW, I looked at this when it was at WG, and I noticed two > operationally particularly bad things that have both bitten us a lot > in our network (and many other networks): > 1) the definition of route resolvability in the presence of > discard/null0/reject/etc. routes is very unfortunate. That is, if > you happen to have to have a default route or an aggregate in your > iBGP, when a router goes down and the loopback matches that route, the > prefixes that were advertised by the router that went down aren't > considered unresolvable, but you have to wait for BGP timeout. > There seemed to be no consensus to change this at this point, as a > DDoS tracing technique depends on that discard/null0 resolvability > "feature". > This was discussed at idr thread: > issue: bgp4-23: route resolvability and discard/null0 routes If memory serves, the discussion resulted in a suggestion to put this consideration in one of the accompanying documents. Sue, Yakov, please check. > 2) The definition of active route is bad. This fails in the > situation where you need to export loopbacks/point-to-points to > eBGP, but you have them in youro IGP. The specification does not > consider them active (not used for forwarding), and they aren't > exported. > When the next-hop of the IGP route is the same as BGP next-hop, > obviously this is no problem. Gargi Nalawade promised to submit > text, but hasn't, and I think Yakov said something about being > willing to incorporate that, but obviously hasn't. > This was discussed at idr thread: > issue 11.2: active route, again > Otherwise, I think this was operationally good. Sue, Yakov, please check if the ball was dropped re this one. Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 19 18:22:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16307 for ; Mon, 19 Apr 2004 18:22:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFh6Y-0003p2-7L for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 18:19:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JMJ6Sv014687 for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 18:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFh33-0002GC-Sp for idr-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 18:15:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15603 for ; Mon, 19 Apr 2004 18:15:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFh30-00027D-VL for idr-web-archive@ietf.org; Mon, 19 Apr 2004 18:15:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFh1x-0001q9-00 for idr-web-archive@ietf.org; Mon, 19 Apr 2004 18:14:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFh0w-0001ZG-00; Mon, 19 Apr 2004 18:13:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgq4-0004Jj-Ey; Mon, 19 Apr 2004 18:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgk5-0001u6-2m for idr@optimus.ietf.org; Mon, 19 Apr 2004 17:55: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 RAA13373 for ; Mon, 19 Apr 2004 17:55:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgk2-0004jq-ET for idr@ietf.org; Mon, 19 Apr 2004 17:55:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFgj8-0004Sd-00 for idr@ietf.org; Mon, 19 Apr 2004 17:54:55 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFgiC-0004BA-00 for idr@ietf.org; Mon, 19 Apr 2004 17:53:56 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFgiB-000Myc-R7; Mon, 19 Apr 2004 21:53:55 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <616478494.20040419145355@psg.com> To: Pekka Savola CC: ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: References: <139156231539.20040319113030@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Mon, 19 Apr 2004 14:53:55 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, [cc'ing IDR] Thanks for a careful follow-up. Inline below, pls. Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote: > On Fri, 19 Mar 2004, Alex Zinin wrote: >> Below is the IETF LC announcement that should have made it to several >> lists and hasn't yet >> >> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html > FWIW, I looked at this when it was at WG, and I noticed two > operationally particularly bad things that have both bitten us a lot > in our network (and many other networks): > 1) the definition of route resolvability in the presence of > discard/null0/reject/etc. routes is very unfortunate. That is, if > you happen to have to have a default route or an aggregate in your > iBGP, when a router goes down and the loopback matches that route, the > prefixes that were advertised by the router that went down aren't > considered unresolvable, but you have to wait for BGP timeout. > There seemed to be no consensus to change this at this point, as a > DDoS tracing technique depends on that discard/null0 resolvability > "feature". > This was discussed at idr thread: > issue: bgp4-23: route resolvability and discard/null0 routes If memory serves, the discussion resulted in a suggestion to put this consideration in one of the accompanying documents. Sue, Yakov, please check. > 2) The definition of active route is bad. This fails in the > situation where you need to export loopbacks/point-to-points to > eBGP, but you have them in youro IGP. The specification does not > consider them active (not used for forwarding), and they aren't > exported. > When the next-hop of the IGP route is the same as BGP next-hop, > obviously this is no problem. Gargi Nalawade promised to submit > text, but hasn't, and I think Yakov said something about being > willing to incorporate that, but obviously hasn't. > This was discussed at idr thread: > issue 11.2: active route, again > Otherwise, I think this was operationally good. Sue, Yakov, please check if the ball was dropped re this one. Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 19 23:37:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02953 for ; Mon, 19 Apr 2004 23:37:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFm4o-0005Tw-0Y for idr-archive@ietf.org; Mon, 19 Apr 2004 23:37:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFm3p-0005Dr-00 for idr-archive@ietf.org; Mon, 19 Apr 2004 23:36:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFm2z-0004za-00; Mon, 19 Apr 2004 23:35:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFlyS-0006Rt-0e; Mon, 19 Apr 2004 23:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFlt6-0005GU-TY for idr@optimus.ietf.org; Mon, 19 Apr 2004 23:25: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 XAA02306 for ; Mon, 19 Apr 2004 23:25:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFlt4-0002OY-Tz for idr@ietf.org; Mon, 19 Apr 2004 23:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFls0-0001uG-00 for idr@ietf.org; Mon, 19 Apr 2004 23:24:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BFlqy-0001Z5-00 for idr@ietf.org; Mon, 19 Apr 2004 23:23:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2004 20:23:48 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3K3MnhE014235 for ; Mon, 19 Apr 2004 20:22:49 -0700 (PDT) Received: from [10.112.0.164] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA22026 for ; Mon, 19 Apr 2004 23:22:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] Multisession as WG doc 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, 19 Apr 2004 15:42:25 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no version=2.60 Hi Folks, I'd like to suggest that Multisession BGP (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working group document. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 19 23:48:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03673 for ; Mon, 19 Apr 2004 23:48:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmBy-0001ZT-Pm for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 23:45:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K3j2JE006028 for idr-archive@odin.ietf.org; Mon, 19 Apr 2004 23:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFm4r-0008Gq-TU for idr-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 23:37:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02980 for ; Mon, 19 Apr 2004 23:37:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFm4p-0005UE-Sv for idr-web-archive@ietf.org; Mon, 19 Apr 2004 23:37:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFm3r-0005E7-00 for idr-web-archive@ietf.org; Mon, 19 Apr 2004 23:36:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFm2z-0004za-00; Mon, 19 Apr 2004 23:35:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFlyS-0006Rt-0e; Mon, 19 Apr 2004 23:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFlt6-0005GU-TY for idr@optimus.ietf.org; Mon, 19 Apr 2004 23:25: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 XAA02306 for ; Mon, 19 Apr 2004 23:25:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFlt4-0002OY-Tz for idr@ietf.org; Mon, 19 Apr 2004 23:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFls0-0001uG-00 for idr@ietf.org; Mon, 19 Apr 2004 23:24:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BFlqy-0001Z5-00 for idr@ietf.org; Mon, 19 Apr 2004 23:23:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2004 20:23:48 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3K3MnhE014235 for ; Mon, 19 Apr 2004 20:22:49 -0700 (PDT) Received: from [10.112.0.164] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA22026 for ; Mon, 19 Apr 2004 23:22:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] Multisession as WG doc 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, 19 Apr 2004 15:42:25 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60 Hi Folks, I'd like to suggest that Multisession BGP (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working group document. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 00:36:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06369 for ; Tue, 20 Apr 2004 00:36:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFn03-0005GE-7i for idr-archive@ietf.org; Tue, 20 Apr 2004 00:36:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmzH-0004zo-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 00:36:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFmyN-0004hm-00; Tue, 20 Apr 2004 00:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmtY-00038q-2Z; Tue, 20 Apr 2004 00:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmoO-0001j3-PT for idr@optimus.ietf.org; Tue, 20 Apr 2004 00:24:44 -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 AAA05687 for ; Tue, 20 Apr 2004 00:24:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFmoM-0002BP-5N for idr@ietf.org; Tue, 20 Apr 2004 00:24:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmnO-0001ws-00 for idr@ietf.org; Tue, 20 Apr 2004 00:23:42 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1BFmmp-0001ie-00 for idr@ietf.org; Tue, 20 Apr 2004 00:23:07 -0400 Received: from [205.168.100.17] (unknown [205.168.100.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id D6E5694621 for ; Mon, 19 Apr 2004 22:23:01 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <68FBC308-9282-11D8-8B6C-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Multisession as WG doc To: idr X-Mailer: Apple Mail (2.613) 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, 19 Apr 2004 22:23:01 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote: > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. I support this - I'm in favor of making it a WG document. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 00:39:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06570 for ; Tue, 20 Apr 2004 00:39: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 1BFn1E-0005JK-Jw for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 00:38:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K4c0GG020406 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 00:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFn08-0004aG-0Q for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 00:36:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06395 for ; Tue, 20 Apr 2004 00:36:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFn05-0005GW-Cv for idr-web-archive@ietf.org; Tue, 20 Apr 2004 00:36:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmzI-000505-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 00:36:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFmyN-0004hm-00; Tue, 20 Apr 2004 00:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmtY-00038q-2Z; Tue, 20 Apr 2004 00:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmoO-0001j3-PT for idr@optimus.ietf.org; Tue, 20 Apr 2004 00:24:44 -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 AAA05687 for ; Tue, 20 Apr 2004 00:24:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFmoM-0002BP-5N for idr@ietf.org; Tue, 20 Apr 2004 00:24:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmnO-0001ws-00 for idr@ietf.org; Tue, 20 Apr 2004 00:23:42 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1BFmmp-0001ie-00 for idr@ietf.org; Tue, 20 Apr 2004 00:23:07 -0400 Received: from [205.168.100.17] (unknown [205.168.100.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id D6E5694621 for ; Mon, 19 Apr 2004 22:23:01 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <68FBC308-9282-11D8-8B6C-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Multisession as WG doc To: idr X-Mailer: Apple Mail (2.613) 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, 19 Apr 2004 22:23:01 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote: > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. I support this - I'm in favor of making it a WG document. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 09:06:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15673 for ; Tue, 20 Apr 2004 09:06:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFux6-0001Ek-VO for idr-archive@ietf.org; Tue, 20 Apr 2004 09:06:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFuw5-0000tu-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 09:05:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFuvL-0000ai-00; Tue, 20 Apr 2004 09:04:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuoO-0006aT-N5; Tue, 20 Apr 2004 08:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFulc-00052u-BM for idr@optimus.ietf.org; Tue, 20 Apr 2004 08:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14545 for ; Tue, 20 Apr 2004 08:54:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFula-000579-Ok for idr@ietf.org; Tue, 20 Apr 2004 08:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFukf-0004oQ-00 for idr@ietf.org; Tue, 20 Apr 2004 08:53:25 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BFujv-0004VN-00 for idr@ietf.org; Tue, 20 Apr 2004 08:52:39 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3KChM6O006336 for ; Tue, 20 Apr 2004 08:52:09 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 4082A75C0005D601; Tue, 20 Apr 2004 08:51:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3AFF@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Support for the prefix limit draft Thread-Index: AcQjAWew+sfOI/IRTseLeKmCHHD90AD0kojgAAA7pZA= From: "Ash, Gerald R (Jerry), ALABS" To: , "Yakov Rekhter" Cc: "Ash, Gerald R (Jerry), ALABS" Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 07:52:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. This draft addresses an important issue, and proposes a reasonable = approach to address the issue. I support this becoming a WG document. Jerry _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 09:26:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16500 for ; Tue, 20 Apr 2004 09:26: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 1BFv8S-0005O5-Nc for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 09:18:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KDI0wI020705 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 09:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFux9-0001nG-Sk for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 09:06: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 JAA15699 for ; Tue, 20 Apr 2004 09:06:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFux8-0001Ew-DW for idr-web-archive@ietf.org; Tue, 20 Apr 2004 09:06:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFuw6-0000u8-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 09:05:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFuvL-0000ai-00; Tue, 20 Apr 2004 09:04:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuoO-0006aT-N5; Tue, 20 Apr 2004 08:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFulc-00052u-BM for idr@optimus.ietf.org; Tue, 20 Apr 2004 08:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14545 for ; Tue, 20 Apr 2004 08:54:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFula-000579-Ok for idr@ietf.org; Tue, 20 Apr 2004 08:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFukf-0004oQ-00 for idr@ietf.org; Tue, 20 Apr 2004 08:53:25 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BFujv-0004VN-00 for idr@ietf.org; Tue, 20 Apr 2004 08:52:39 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3KChM6O006336 for ; Tue, 20 Apr 2004 08:52:09 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 4082A75C0005D601; Tue, 20 Apr 2004 08:51:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3AFF@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Support for the prefix limit draft Thread-Index: AcQjAWew+sfOI/IRTseLeKmCHHD90AD0kojgAAA7pZA= From: "Ash, Gerald R (Jerry), ALABS" To: , "Yakov Rekhter" Cc: "Ash, Gerald R (Jerry), ALABS" Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 07:52:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. This draft addresses an important issue, and proposes a reasonable = approach to address the issue. I support this becoming a WG document. Jerry _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 10:13:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20288 for ; Tue, 20 Apr 2004 10:13:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFw0J-0004lH-UQ for idr-archive@ietf.org; Tue, 20 Apr 2004 10:13:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvyh-0004Jt-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 10:12:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFvxj-00041T-00; Tue, 20 Apr 2004 10:10:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvqz-0002F0-H7; Tue, 20 Apr 2004 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFviO-0002F5-5G for idr@optimus.ietf.org; Tue, 20 Apr 2004 09:55: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 JAA18099 for ; Tue, 20 Apr 2004 09:55:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFviM-0006rz-5L for idr@ietf.org; Tue, 20 Apr 2004 09:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvhW-0006cW-00 for idr@ietf.org; Tue, 20 Apr 2004 09:54:14 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BFvgz-0006MJ-00 for idr@ietf.org; Tue, 20 Apr 2004 09:53:41 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3KDr7l13986; Tue, 20 Apr 2004 06:53:07 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KDr1J39724; Tue, 20 Apr 2004 06:53:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201353.i3KDr1J39724@merlot.juniper.net> To: Alex Zinin cc: Pekka Savola , ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: Your message of "Mon, 19 Apr 2004 14:53:55 PDT." <616478494.20040419145355@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42442.1082469181.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 06:53:01 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex, > Pekka, > > [cc'ing IDR] > > Thanks for a careful follow-up. Inline below, pls. > > Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote: > > On Fri, 19 Mar 2004, Alex Zinin wrote: > >> Below is the IETF LC announcement that should have made it to several > >> lists and hasn't yet > >> > >> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html > > > FWIW, I looked at this when it was at WG, and I noticed two > > operationally particularly bad things that have both bitten us a lot > > in our network (and many other networks): > > > 1) the definition of route resolvability in the presence of > > discard/null0/reject/etc. routes is very unfortunate. That is, if > > you happen to have to have a default route or an aggregate in your > > iBGP, when a router goes down and the loopback matches that route, the > > prefixes that were advertised by the router that went down aren't > > considered unresolvable, but you have to wait for BGP timeout. > > > There seemed to be no consensus to change this at this point, as a > > DDoS tracing technique depends on that discard/null0 resolvability > > "feature". > > > > > > This was discussed at idr thread: > > > > issue: bgp4-23: route resolvability and discard/null0 routes > > If memory serves, the discussion resulted in a suggestion to put this > consideration in one of the accompanying documents. Sue, Yakov, please > check. The suggestion on the mailing list was *not* to put this consideration into one of the accompanying documents, but to produce a *separate* Internet Draft that cover this (see e-mails on 3/12/2004). > > 2) The definition of active route is bad. This fails in the > > situation where you need to export loopbacks/point-to-points to > > eBGP, but you have them in youro IGP. The specification does not > > consider them active (not used for forwarding), and they aren't > > exported. > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > obviously this is no problem. Gargi Nalawade promised to submit > > text, but hasn't, and I think Yakov said something about being > > willing to incorporate that, but obviously hasn't. > > > > This was discussed at idr thread: > > > issue 11.2: active route, again > > > Otherwise, I think this was operationally good. > > Sue, Yakov, please check if the ball was dropped re this one. First of all, the consensus of the WG (as documented in draft-ietf-idr-bgp-issues) is to have the following text: In the context of this document we assume that a BGP speaker advertises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. While this text does not cover the case described by Pekka, it does not preclude it either - handling the case described by Pekka is just outside the scope of the spec. With this in mind I suggest that the case described by Pekka should be covered in a separate Internet Draft. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 10:16:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20836 for ; Tue, 20 Apr 2004 10:16:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFw2w-0005hy-Av for idr-archive@ietf.org; Tue, 20 Apr 2004 10:16:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFw1x-0005Ph-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 10:15:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFw1M-00057I-00; Tue, 20 Apr 2004 10:14:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvry-0002mF-VO; Tue, 20 Apr 2004 10:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvkT-0005Ec-66 for idr@optimus.ietf.org; Tue, 20 Apr 2004 09:57:17 -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 JAA18226 for ; Tue, 20 Apr 2004 09:57:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvkR-0007UG-4L for idr@ietf.org; Tue, 20 Apr 2004 09:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvjV-0007C3-00 for idr@ietf.org; Tue, 20 Apr 2004 09:56:18 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BFvia-0006d7-00 for idr@ietf.org; Tue, 20 Apr 2004 09:55:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3KDsfBm078422; Tue, 20 Apr 2004 06:54:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KDsbJ39849; Tue, 20 Apr 2004 06:54:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201354.i3KDsbJ39849@merlot.juniper.net> To: Stephen Kent cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 16 Apr 2004 18:50:54 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42557.1082469277.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 06:54:37 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Steve, > >> >Steve, would you mind making a suggestion on how the text could > >>be improved? > >> >E.g., would a separate section in the main body of the document specifyi ng > >> >the requirement for TCP-MD5 support be useful? > >> > >> A reasonable approach would be to have a section of the document that > >> describes the use of this TCP option. It should explain why/when one > >> would use the option in the context of BGP links and what protection > >> it offers. > > > >Would you please produce the appropriate text for this section. > > > >Thanks in advance. > > > >Yakov. > > I'll try to provide some text when I return from vacation, in early May. Thanks !!! Looking forward to get the text. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 10:31:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21656 for ; Tue, 20 Apr 2004 10:31:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwHA-0001sZ-QB for idr-archive@ietf.org; Tue, 20 Apr 2004 10:31:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwGD-0001ce-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 10:30:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwFZ-0001NZ-00; Tue, 20 Apr 2004 10:29:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFw2f-0003NG-Ix; Tue, 20 Apr 2004 10:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvtv-0003gi-1s for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:07:03 -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 KAA19472 for ; Tue, 20 Apr 2004 10:06:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvts-0002tx-NE for idr@ietf.org; Tue, 20 Apr 2004 10:07:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvst-0002c0-00 for idr@ietf.org; Tue, 20 Apr 2004 10:05:59 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BFvrt-00024P-00 for idr@ietf.org; Tue, 20 Apr 2004 10:04:57 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3KE4Q5G022841 for ; Tue, 20 Apr 2004 07:04:26 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3KE4Qa6022840 for idr@ietf.org; Tue, 20 Apr 2004 07:04:26 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f From: David Meyer To: idr Subject: Re: [Idr] Multisession as WG doc Message-ID: <20040420140426.GB22815@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon 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, 20 Apr 2004 07:04:26 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote: >Hi Folks, > >I'd like to suggest that Multisession BGP >(draft-scudder-bgp-multisession-00.txt) be considered as an IDR >working group document. I support this document becoming a WG document. Dave _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 10:31:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21711 for ; Tue, 20 Apr 2004 10:31:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFw3d-0003kn-Kx for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 10:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KEH5Uf014423 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 10:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFw0N-0007sb-Jd for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 10:13: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 KAA20312 for ; Tue, 20 Apr 2004 10:13:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFw0L-0004lR-C5 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:13:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvyj-0004K7-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:12:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFvxj-00041T-00; Tue, 20 Apr 2004 10:10:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvqz-0002F0-H7; Tue, 20 Apr 2004 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFviO-0002F5-5G for idr@optimus.ietf.org; Tue, 20 Apr 2004 09:55: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 JAA18099 for ; Tue, 20 Apr 2004 09:55:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFviM-0006rz-5L for idr@ietf.org; Tue, 20 Apr 2004 09:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvhW-0006cW-00 for idr@ietf.org; Tue, 20 Apr 2004 09:54:14 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BFvgz-0006MJ-00 for idr@ietf.org; Tue, 20 Apr 2004 09:53:41 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3KDr7l13986; Tue, 20 Apr 2004 06:53:07 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KDr1J39724; Tue, 20 Apr 2004 06:53:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201353.i3KDr1J39724@merlot.juniper.net> To: Alex Zinin cc: Pekka Savola , ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: Your message of "Mon, 19 Apr 2004 14:53:55 PDT." <616478494.20040419145355@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42442.1082469181.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 06:53:01 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex, > Pekka, > > [cc'ing IDR] > > Thanks for a careful follow-up. Inline below, pls. > > Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote: > > On Fri, 19 Mar 2004, Alex Zinin wrote: > >> Below is the IETF LC announcement that should have made it to several > >> lists and hasn't yet > >> > >> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html > > > FWIW, I looked at this when it was at WG, and I noticed two > > operationally particularly bad things that have both bitten us a lot > > in our network (and many other networks): > > > 1) the definition of route resolvability in the presence of > > discard/null0/reject/etc. routes is very unfortunate. That is, if > > you happen to have to have a default route or an aggregate in your > > iBGP, when a router goes down and the loopback matches that route, the > > prefixes that were advertised by the router that went down aren't > > considered unresolvable, but you have to wait for BGP timeout. > > > There seemed to be no consensus to change this at this point, as a > > DDoS tracing technique depends on that discard/null0 resolvability > > "feature". > > > > > > This was discussed at idr thread: > > > > issue: bgp4-23: route resolvability and discard/null0 routes > > If memory serves, the discussion resulted in a suggestion to put this > consideration in one of the accompanying documents. Sue, Yakov, please > check. The suggestion on the mailing list was *not* to put this consideration into one of the accompanying documents, but to produce a *separate* Internet Draft that cover this (see e-mails on 3/12/2004). > > 2) The definition of active route is bad. This fails in the > > situation where you need to export loopbacks/point-to-points to > > eBGP, but you have them in youro IGP. The specification does not > > consider them active (not used for forwarding), and they aren't > > exported. > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > obviously this is no problem. Gargi Nalawade promised to submit > > text, but hasn't, and I think Yakov said something about being > > willing to incorporate that, but obviously hasn't. > > > > This was discussed at idr thread: > > > issue 11.2: active route, again > > > Otherwise, I think this was operationally good. > > Sue, Yakov, please check if the ball was dropped re this one. First of all, the consensus of the WG (as documented in draft-ietf-idr-bgp-issues) is to have the following text: In the context of this document we assume that a BGP speaker advertises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. While this text does not cover the case described by Pekka, it does not preclude it either - handling the case described by Pekka is just outside the scope of the spec. With this in mind I suggest that the case described by Pekka should be covered in a separate Internet Draft. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 10:32:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21794 for ; Tue, 20 Apr 2004 10:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwGV-0000Au-4w for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 10:30:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KEUNnE000668 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 10:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFw30-0003Uh-0q for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 10:16:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20860 for ; Tue, 20 Apr 2004 10:16:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFw2x-0005iB-O7 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:16:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFw1y-0005Pw-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:15:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFw1M-00057I-00; Tue, 20 Apr 2004 10:14:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvry-0002mF-VO; Tue, 20 Apr 2004 10:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvkT-0005Ec-66 for idr@optimus.ietf.org; Tue, 20 Apr 2004 09:57:17 -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 JAA18226 for ; Tue, 20 Apr 2004 09:57:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvkR-0007UG-4L for idr@ietf.org; Tue, 20 Apr 2004 09:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvjV-0007C3-00 for idr@ietf.org; Tue, 20 Apr 2004 09:56:18 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BFvia-0006d7-00 for idr@ietf.org; Tue, 20 Apr 2004 09:55:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3KDsfBm078422; Tue, 20 Apr 2004 06:54:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KDsbJ39849; Tue, 20 Apr 2004 06:54:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201354.i3KDsbJ39849@merlot.juniper.net> To: Stephen Kent cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 16 Apr 2004 18:50:54 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42557.1082469277.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 06:54:37 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Steve, > >> >Steve, would you mind making a suggestion on how the text could > >>be improved? > >> >E.g., would a separate section in the main body of the document specifyi ng > >> >the requirement for TCP-MD5 support be useful? > >> > >> A reasonable approach would be to have a section of the document that > >> describes the use of this TCP option. It should explain why/when one > >> would use the option in the context of BGP links and what protection > >> it offers. > > > >Would you please produce the appropriate text for this section. > > > >Thanks in advance. > > > >Yakov. > > I'll try to provide some text when I return from vacation, in early May. Thanks !!! Looking forward to get the text. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 10:40:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22350 for ; Tue, 20 Apr 2004 10:40: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 1BFwNI-0002SS-BG for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 10:37:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KEbOul009443 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 10:37:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwHF-0000ci-FJ for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 10:31: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 KAA21679 for ; Tue, 20 Apr 2004 10:31:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwHD-0001ss-4B for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:31:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwGF-0001cw-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:30:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwFZ-0001NZ-00; Tue, 20 Apr 2004 10:29:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFw2f-0003NG-Ix; Tue, 20 Apr 2004 10:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvtv-0003gi-1s for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:07:03 -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 KAA19472 for ; Tue, 20 Apr 2004 10:06:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvts-0002tx-NE for idr@ietf.org; Tue, 20 Apr 2004 10:07:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvst-0002c0-00 for idr@ietf.org; Tue, 20 Apr 2004 10:05:59 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BFvrt-00024P-00 for idr@ietf.org; Tue, 20 Apr 2004 10:04:57 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3KE4Q5G022841 for ; Tue, 20 Apr 2004 07:04:26 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3KE4Qa6022840 for idr@ietf.org; Tue, 20 Apr 2004 07:04:26 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f From: David Meyer To: idr Subject: Re: [Idr] Multisession as WG doc Message-ID: <20040420140426.GB22815@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon 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, 20 Apr 2004 07:04:26 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote: >Hi Folks, > >I'd like to suggest that Multisession BGP >(draft-scudder-bgp-multisession-00.txt) be considered as an IDR >working group document. I support this document becoming a WG document. Dave _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 10:59:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23530 for ; Tue, 20 Apr 2004 10:59:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwiO-0001wX-53 for idr-archive@ietf.org; Tue, 20 Apr 2004 10:59:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwhX-0001g5-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 10:58:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwh1-0001PF-00; Tue, 20 Apr 2004 10:57:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwQ1-0003t5-Pk; Tue, 20 Apr 2004 10:40:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwN1-0002EF-5Q for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:37:07 -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 KAA22095 for ; Tue, 20 Apr 2004 10:37:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwMy-0003ZU-Nx for idr@ietf.org; Tue, 20 Apr 2004 10:37:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwLy-0003IU-00 for idr@ietf.org; Tue, 20 Apr 2004 10:36:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BFwL1-0002ns-00 for idr@ietf.org; Tue, 20 Apr 2004 10:35:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2004 07:46:55 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (dhcp-kta1-161-44-192-234.cisco.com [161.44.192.234]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3KEYUAH012869 for ; Tue, 20 Apr 2004 10:34:31 -0400 (EDT) From: "zafar ali" To: "'idr'" Subject: RE: [Idr] Multisession as WG doc Organization: Cisco Systems Message-ID: <000001c426e4$9e959a60$eac02ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: <68FBC308-9282-11D8-8B6C-000393D54EA6@tcb.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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, 20 Apr 2004 10:34:38 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. I support this notion. Thanks Regards... Zafar _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 11:01:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23685 for ; Tue, 20 Apr 2004 11:01:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwkM-0002WJ-7L for idr-archive@ietf.org; Tue, 20 Apr 2004 11:01:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwjV-0002Fd-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 11:00:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwii-0001yc-00; Tue, 20 Apr 2004 10:59:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwQo-0003v9-MA; Tue, 20 Apr 2004 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwOz-0003Ho-Tb for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:39: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 KAA22237 for ; Tue, 20 Apr 2004 10:39:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwOx-00048q-IH for idr@ietf.org; Tue, 20 Apr 2004 10:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwO2-0003ra-00 for idr@ietf.org; Tue, 20 Apr 2004 10:38:11 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BFwN5-0003Km-00 for idr@ietf.org; Tue, 20 Apr 2004 10:37:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3KEafBm078544 for ; Tue, 20 Apr 2004 07:36:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KEafJ43860 for ; Tue, 20 Apr 2004 07:36:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201436.i3KEafJ43860@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48430.1082471801.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-scudder-bgp-multisession-00.txt as an IDR WG document 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, 20 Apr 2004 07:36:41 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Please comment on the attached. The deadline for comments is May 3. Yakov. ------- Forwarded Message Date: Mon, 19 Apr 2004 15:42:25 -0400 From: "John G. Scudder" To: idr@ietf.org Subject: [Idr] Multisession as WG doc Hi Folks, I'd like to suggest that Multisession BGP (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working group document. Thanks, - --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 11:21:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24921 for ; Tue, 20 Apr 2004 11:21: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 1BFwlG-0002Su-VF for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 11:02:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KF2Ap1009468 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 11:02:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwiS-0001QX-5u for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 10:59: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 KAA23556 for ; Tue, 20 Apr 2004 10:59:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwiP-0001wj-J0 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:59:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwhY-0001gJ-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 10:58:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwh1-0001PF-00; Tue, 20 Apr 2004 10:57:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwQ1-0003t5-Pk; Tue, 20 Apr 2004 10:40:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwN1-0002EF-5Q for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:37:07 -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 KAA22095 for ; Tue, 20 Apr 2004 10:37:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwMy-0003ZU-Nx for idr@ietf.org; Tue, 20 Apr 2004 10:37:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwLy-0003IU-00 for idr@ietf.org; Tue, 20 Apr 2004 10:36:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BFwL1-0002ns-00 for idr@ietf.org; Tue, 20 Apr 2004 10:35:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2004 07:46:55 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (dhcp-kta1-161-44-192-234.cisco.com [161.44.192.234]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3KEYUAH012869 for ; Tue, 20 Apr 2004 10:34:31 -0400 (EDT) From: "zafar ali" To: "'idr'" Subject: RE: [Idr] Multisession as WG doc Organization: Cisco Systems Message-ID: <000001c426e4$9e959a60$eac02ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: <68FBC308-9282-11D8-8B6C-000393D54EA6@tcb.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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, 20 Apr 2004 10:34:38 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. I support this notion. Thanks Regards... Zafar _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 11:40:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26895 for ; Tue, 20 Apr 2004 11:40: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 1BFwlv-0002e2-Vz for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 11:02:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KF2pvX010158 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 11:02:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwkQ-0001vv-5e for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 11:01:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23711 for ; Tue, 20 Apr 2004 11:01:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwkN-0002WV-Jz for idr-web-archive@ietf.org; Tue, 20 Apr 2004 11:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwjX-0002Fs-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 11:00:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwii-0001yc-00; Tue, 20 Apr 2004 10:59:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwQo-0003v9-MA; Tue, 20 Apr 2004 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwOz-0003Ho-Tb for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:39: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 KAA22237 for ; Tue, 20 Apr 2004 10:39:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwOx-00048q-IH for idr@ietf.org; Tue, 20 Apr 2004 10:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwO2-0003ra-00 for idr@ietf.org; Tue, 20 Apr 2004 10:38:11 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BFwN5-0003Km-00 for idr@ietf.org; Tue, 20 Apr 2004 10:37:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3KEafBm078544 for ; Tue, 20 Apr 2004 07:36:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KEafJ43860 for ; Tue, 20 Apr 2004 07:36:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201436.i3KEafJ43860@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48430.1082471801.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-scudder-bgp-multisession-00.txt as an IDR WG document 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, 20 Apr 2004 07:36:41 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Please comment on the attached. The deadline for comments is May 3. Yakov. ------- Forwarded Message Date: Mon, 19 Apr 2004 15:42:25 -0400 From: "John G. Scudder" To: idr@ietf.org Subject: [Idr] Multisession as WG doc Hi Folks, I'd like to suggest that Multisession BGP (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working group document. Thanks, - --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 14:56:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12589 for ; Tue, 20 Apr 2004 14:56:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0Pm-0000XZ-R6 for idr-archive@ietf.org; Tue, 20 Apr 2004 14:56:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0Ot-0000UH-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 14:55:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG0OM-0000Qp-00; Tue, 20 Apr 2004 14:54:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG09B-0008NT-Ep; Tue, 20 Apr 2004 14:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG02U-0005cA-1P for idr@optimus.ietf.org; Tue, 20 Apr 2004 14:32: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 OAA10528 for ; Tue, 20 Apr 2004 14:32:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG02R-0006ML-D4 for idr@ietf.org; Tue, 20 Apr 2004 14:32:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG01U-0006IN-00 for idr@ietf.org; Tue, 20 Apr 2004 14:31:09 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BG00Y-0006CX-00 for idr@ietf.org; Tue, 20 Apr 2004 14:30:10 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWH00837F3DY0@firewall.mci.com> for idr@ietf.org; Tue, 20 Apr 2004 18:23:37 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWH00I01EYSMM@pmismtp02.mcilink.com>; Tue, 20 Apr 2004 18:23:37 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWH00I2TF12ME@pmismtp02.mcilink.com>; Tue, 20 Apr 2004 18:22:14 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-reply-to: <9473683187ADC049A855ED2DA739ABCA02BA3AFF@KCCLUST06EVS1.ugd.att.com> To: "'Ash, Gerald R (Jerry), ALABS'" , idr@ietf.org, "'Yakov Rekhter'" Message-id: <009a01c42704$67888850$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 14:22:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This draft proposes some reasonable approach to solve some existing = issues.=20 In VPN world the number of prefixes can slowly creep up and an elaborate mechanism for warning, stop and reset could be helpful but in public SP world in most of the cases the SP maintains a static prefix-list for = each customer. Usually the customer needs to contact the SP if they need to modify that prefix-list.=20 Typically though, the SP accepts any prefixes which are more specific to = the ones maintained in the prefix-list filter. The problem arises when the customer accidentally de-aggregates their prefixes. And when that = happens depending on the block that got de-aggregated, the number prefix send by customer could experience a sudden sizeable jump. In today's world, = there is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session = would go down permanently if the max-prefix-limit is exceeded. It would take = an urgent operator intervention to bring it up again, of course the = operator would need to make sure the cause has been taken care off before = bringing the session up. So if we want to use the draft approach to take care of this particular scenario, a filtering mechanism depending on the specificity of a prefix could become important. For, e.g., if a session hits the stop level, the sender could resend all its prefixes after filtering out any prefix more specific to /24 etc. Of course this specificity should be configurable. However, if for example, /24 is chosen, it would ensure all the customer prefixes are still globally routable, but some of their load-balancing mechanism can get affected. So the price the customer pays for the = mishap gets less harsh. On the other hand, the approach mentioned in the draft could be useful = on the BGP sessions used for peering with equivalent SP peers. -Parantap =20 -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Ash, Gerald R (Jerry), ALABS Sent: Tuesday, April 20, 2004 8:52 AM To: idr@ietf.org; Yakov Rekhter Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. This draft addresses an important issue, and proposes a reasonable = approach to address the issue. I support this becoming a WG document. Jerry _______________________________________________ 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 Apr 20 15:19:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15531 for ; Tue, 20 Apr 2004 15:19:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Tm-0008Sg-Ho for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 15:00:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KJ0MJK032496 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 15:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Pr-0006Hi-IK for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 14:56: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 OAA12619 for ; Tue, 20 Apr 2004 14:56:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0Po-0000Xj-NC for idr-web-archive@ietf.org; Tue, 20 Apr 2004 14:56:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0Ou-0000UV-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 14:55:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG0OM-0000Qp-00; Tue, 20 Apr 2004 14:54:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG09B-0008NT-Ep; Tue, 20 Apr 2004 14:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG02U-0005cA-1P for idr@optimus.ietf.org; Tue, 20 Apr 2004 14:32: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 OAA10528 for ; Tue, 20 Apr 2004 14:32:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG02R-0006ML-D4 for idr@ietf.org; Tue, 20 Apr 2004 14:32:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG01U-0006IN-00 for idr@ietf.org; Tue, 20 Apr 2004 14:31:09 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BG00Y-0006CX-00 for idr@ietf.org; Tue, 20 Apr 2004 14:30:10 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWH00837F3DY0@firewall.mci.com> for idr@ietf.org; Tue, 20 Apr 2004 18:23:37 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWH00I01EYSMM@pmismtp02.mcilink.com>; Tue, 20 Apr 2004 18:23:37 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWH00I2TF12ME@pmismtp02.mcilink.com>; Tue, 20 Apr 2004 18:22:14 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-reply-to: <9473683187ADC049A855ED2DA739ABCA02BA3AFF@KCCLUST06EVS1.ugd.att.com> To: "'Ash, Gerald R (Jerry), ALABS'" , idr@ietf.org, "'Yakov Rekhter'" Message-id: <009a01c42704$67888850$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 14:22:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This draft proposes some reasonable approach to solve some existing = issues.=20 In VPN world the number of prefixes can slowly creep up and an elaborate mechanism for warning, stop and reset could be helpful but in public SP world in most of the cases the SP maintains a static prefix-list for = each customer. Usually the customer needs to contact the SP if they need to modify that prefix-list.=20 Typically though, the SP accepts any prefixes which are more specific to = the ones maintained in the prefix-list filter. The problem arises when the customer accidentally de-aggregates their prefixes. And when that = happens depending on the block that got de-aggregated, the number prefix send by customer could experience a sudden sizeable jump. In today's world, = there is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session = would go down permanently if the max-prefix-limit is exceeded. It would take = an urgent operator intervention to bring it up again, of course the = operator would need to make sure the cause has been taken care off before = bringing the session up. So if we want to use the draft approach to take care of this particular scenario, a filtering mechanism depending on the specificity of a prefix could become important. For, e.g., if a session hits the stop level, the sender could resend all its prefixes after filtering out any prefix more specific to /24 etc. Of course this specificity should be configurable. However, if for example, /24 is chosen, it would ensure all the customer prefixes are still globally routable, but some of their load-balancing mechanism can get affected. So the price the customer pays for the = mishap gets less harsh. On the other hand, the approach mentioned in the draft could be useful = on the BGP sessions used for peering with equivalent SP peers. -Parantap =20 -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Ash, Gerald R (Jerry), ALABS Sent: Tuesday, April 20, 2004 8:52 AM To: idr@ietf.org; Yakov Rekhter Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. This draft addresses an important issue, and proposes a reasonable = approach to address the issue. I support this becoming a WG document. Jerry _______________________________________________ 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 Apr 20 16:24:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20823 for ; Tue, 20 Apr 2004 16:24:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1n8-0000ZP-7r for idr-archive@ietf.org; Tue, 20 Apr 2004 16:24:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1mC-0000SJ-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 16:23:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG1lK-0000M7-00; Tue, 20 Apr 2004 16:22:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1PV-0000O6-Eg; Tue, 20 Apr 2004 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Ft-0005GD-2U for idr@optimus.ietf.org; Tue, 20 Apr 2004 15:50:05 -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 PAA17884 for ; Tue, 20 Apr 2004 15:50:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1Fr-000503-F8 for idr@ietf.org; Tue, 20 Apr 2004 15:50:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1En-0004pQ-00 for idr@ietf.org; Tue, 20 Apr 2004 15:48:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BG1Dg-0004d2-00 for idr@ietf.org; Tue, 20 Apr 2004 15:47:48 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 Apr 2004 12:48:23 -0700 Received: from cisco.com ([128.107.177.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3KJlGqi021754 for ; Tue, 20 Apr 2004 12:47:16 -0700 (PDT) Message-ID: <40857E4F.3040304@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: [Idr] Soft-Notify as IDR WG document Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.82] X-PMX-Version: 4.5.0.92886 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, 20 Apr 2004 12:47:27 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi All, I would like to request that BGP Soft-Notify draft, draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG document. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 20 18:00:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29891 for ; Tue, 20 Apr 2004 18:00: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 1BG2ul-0002cL-W4 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 17:36:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KLaNdw010055 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 17:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1nD-00050n-8G for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 16:24: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 QAA20851 for ; Tue, 20 Apr 2004 16:24:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1nB-0000Zt-Ce for idr-web-archive@ietf.org; Tue, 20 Apr 2004 16:24:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1mD-0000Sa-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 16:23:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG1lK-0000M7-00; Tue, 20 Apr 2004 16:22:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1PV-0000O6-Eg; Tue, 20 Apr 2004 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Ft-0005GD-2U for idr@optimus.ietf.org; Tue, 20 Apr 2004 15:50:05 -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 PAA17884 for ; Tue, 20 Apr 2004 15:50:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1Fr-000503-F8 for idr@ietf.org; Tue, 20 Apr 2004 15:50:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1En-0004pQ-00 for idr@ietf.org; Tue, 20 Apr 2004 15:48:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BG1Dg-0004d2-00 for idr@ietf.org; Tue, 20 Apr 2004 15:47:48 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 Apr 2004 12:48:23 -0700 Received: from cisco.com ([128.107.177.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3KJlGqi021754 for ; Tue, 20 Apr 2004 12:47:16 -0700 (PDT) Message-ID: <40857E4F.3040304@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: [Idr] Soft-Notify as IDR WG document Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.82] X-PMX-Version: 4.5.0.92886 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, 20 Apr 2004 12:47:27 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, I would like to request that BGP Soft-Notify draft, draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG document. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 20 23:54:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20761 for ; Tue, 20 Apr 2004 23:54:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8ob-0004UO-3a for idr-archive@ietf.org; Tue, 20 Apr 2004 23:54:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8nh-0004PW-00 for idr-archive@ietf.org; Tue, 20 Apr 2004 23:53:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG8n5-0004LI-00; Tue, 20 Apr 2004 23:52:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8gX-0001rf-ST; Tue, 20 Apr 2004 23:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8UH-0004ub-2o for idr@optimus.ietf.org; Tue, 20 Apr 2004 23:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19846 for ; Tue, 20 Apr 2004 23:33:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8UE-0002dF-SF for idr@ietf.org; Tue, 20 Apr 2004 23:33:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8TG-0002YN-00 for idr@ietf.org; Tue, 20 Apr 2004 23:32:22 -0400 Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx with esmtp (Exim 4.12) id 1BG8SG-0002QG-00 for idr@ietf.org; Tue, 20 Apr 2004 23:31:20 -0400 Received: by mail.castlepoint.net (Postfix, from userid 500) id 6472513AC8; Tue, 20 Apr 2004 21:31:20 -0600 (MDT) From: Shane Amante To: idr@ietf.org Subject: Re: [Idr] Multisession as WG doc Message-ID: <20040421033120.GA1689@ns1.castlepoint.net> Mail-Followup-To: idr@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i 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, 20 Apr 2004 21:31:20 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I support making this a WG document. -shane On Mon, Apr 19, 2004 at 03:42:25PM -0400, John G. Scudder wrote: > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 21 00:01:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21106 for ; Wed, 21 Apr 2004 00:01: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 1BG8tg-0007oV-Uc for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 23:59:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3xeMw030027 for idr-archive@odin.ietf.org; Tue, 20 Apr 2004 23:59:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8oe-0005An-LM for idr-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20787 for ; Tue, 20 Apr 2004 23:54:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8oc-0004UY-Cr for idr-web-archive@ietf.org; Tue, 20 Apr 2004 23:54:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8ni-0004Pl-00 for idr-web-archive@ietf.org; Tue, 20 Apr 2004 23:53:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG8n5-0004LI-00; Tue, 20 Apr 2004 23:52:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8gX-0001rf-ST; Tue, 20 Apr 2004 23:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8UH-0004ub-2o for idr@optimus.ietf.org; Tue, 20 Apr 2004 23:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19846 for ; Tue, 20 Apr 2004 23:33:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8UE-0002dF-SF for idr@ietf.org; Tue, 20 Apr 2004 23:33:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8TG-0002YN-00 for idr@ietf.org; Tue, 20 Apr 2004 23:32:22 -0400 Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx with esmtp (Exim 4.12) id 1BG8SG-0002QG-00 for idr@ietf.org; Tue, 20 Apr 2004 23:31:20 -0400 Received: by mail.castlepoint.net (Postfix, from userid 500) id 6472513AC8; Tue, 20 Apr 2004 21:31:20 -0600 (MDT) From: Shane Amante To: idr@ietf.org Subject: Re: [Idr] Multisession as WG doc Message-ID: <20040421033120.GA1689@ns1.castlepoint.net> Mail-Followup-To: idr@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i 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, 20 Apr 2004 21:31:20 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I support making this a WG document. -shane On Mon, Apr 19, 2004 at 03:42:25PM -0400, John G. Scudder wrote: > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 21 17:17:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14972 for ; Wed, 21 Apr 2004 17:17:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGP5m-0000EG-KT for idr-archive@ietf.org; Wed, 21 Apr 2004 17:17:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP4m-0007nH-00 for idr-archive@ietf.org; Wed, 21 Apr 2004 17:16:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGP3w-0007b4-00; Wed, 21 Apr 2004 17:15:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOaj-0003ya-8z; Wed, 21 Apr 2004 16:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGMZr-0005Nv-75 for idr@optimus.ietf.org; Wed, 21 Apr 2004 14:36:07 -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 OAA06463 for ; Wed, 21 Apr 2004 14:36:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGMZo-0002m8-EP for idr@ietf.org; Wed, 21 Apr 2004 14:36:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGMYn-0002c5-00 for idr@ietf.org; Wed, 21 Apr 2004 14:35:02 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BGMXu-0002KL-00 for idr@ietf.org; Wed, 21 Apr 2004 14:34:06 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3LIXa5O005557; Wed, 21 Apr 2004 11:33:36 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3LIXZiD005554; Wed, 21 Apr 2004 11:33:35 -0700 (PDT) Message-Id: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <200404162122.i3GLMoJ87986@merlot.juniper.net> References: <200404162122.i3GLMoJ87986@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 21 Apr 2004 11:33:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > Folks, It would be greatly appreciated if folks would read the > document and comment on it to the IDR mailing list. In other words, > we need "yes, looks good" or "should fix this and that", not just > silence. my recollection is that this draft has been discussed before and that the majority of the WG requested that encoding and applications of communities be kept separate. reclying the comments: it does appear that the propossed applications are possible w/ existing protocol support. The author recognises that some of those applications may or may not be a good idea given that they seem to impose on an ISP a set of policies which the ISP may or may not wish to provide... reading the document, it seems that the original comments are still relevant. i also believe that embeding ipv4 and ipv6 addresses into communities is not a feature... addresses don't make for very good identifiers given that they may change. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 21 18:29:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24470 for ; Wed, 21 Apr 2004 18:29:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPr0-0003e6-QC for idr-archive@odin.ietf.org; Wed, 21 Apr 2004 18:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM62Ga014009 for idr-archive@odin.ietf.org; Wed, 21 Apr 2004 18: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 1BGP5q-0001Qp-Mo for idr-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:17:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15002 for ; Wed, 21 Apr 2004 17:17:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGP5o-0000ET-FY for idr-web-archive@ietf.org; Wed, 21 Apr 2004 17:17:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP4n-0007nV-00 for idr-web-archive@ietf.org; Wed, 21 Apr 2004 17:16:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGP3w-0007b4-00; Wed, 21 Apr 2004 17:15:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOaj-0003ya-8z; Wed, 21 Apr 2004 16:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGMZr-0005Nv-75 for idr@optimus.ietf.org; Wed, 21 Apr 2004 14:36:07 -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 OAA06463 for ; Wed, 21 Apr 2004 14:36:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGMZo-0002m8-EP for idr@ietf.org; Wed, 21 Apr 2004 14:36:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGMYn-0002c5-00 for idr@ietf.org; Wed, 21 Apr 2004 14:35:02 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BGMXu-0002KL-00 for idr@ietf.org; Wed, 21 Apr 2004 14:34:06 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3LIXa5O005557; Wed, 21 Apr 2004 11:33:36 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3LIXZiD005554; Wed, 21 Apr 2004 11:33:35 -0700 (PDT) Message-Id: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <200404162122.i3GLMoJ87986@merlot.juniper.net> References: <200404162122.i3GLMoJ87986@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 21 Apr 2004 11:33:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > Folks, It would be greatly appreciated if folks would read the > document and comment on it to the IDR mailing list. In other words, > we need "yes, looks good" or "should fix this and that", not just > silence. my recollection is that this draft has been discussed before and that the majority of the WG requested that encoding and applications of communities be kept separate. reclying the comments: it does appear that the propossed applications are possible w/ existing protocol support. The author recognises that some of those applications may or may not be a good idea given that they seem to impose on an ISP a set of policies which the ISP may or may not wish to provide... reading the document, it seems that the original comments are still relevant. i also believe that embeding ipv4 and ipv6 addresses into communities is not a feature... addresses don't make for very good identifiers given that they may change. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 22 05:36:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14407 for ; Thu, 22 Apr 2004 05:36:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGadV-0002Ox-0U for idr-archive@ietf.org; Thu, 22 Apr 2004 05:36:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGacW-00029a-00 for idr-archive@ietf.org; Thu, 22 Apr 2004 05:35:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGabk-0001u6-00; Thu, 22 Apr 2004 05:35:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaPF-0006zD-CQ; Thu, 22 Apr 2004 05:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaN7-0005SH-5j for idr@optimus.ietf.org; Thu, 22 Apr 2004 05:19: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 FAA13806 for ; Thu, 22 Apr 2004 05:19:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaN1-0006Lx-Vc for idr@ietf.org; Thu, 22 Apr 2004 05:19:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaM7-00068s-00 for idr@ietf.org; Thu, 22 Apr 2004 05:18:51 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGaLi-0005vS-00 for idr@ietf.org; Thu, 22 Apr 2004 05:18:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3M9Hr903947; Thu, 22 Apr 2004 12:17:53 +0300 From: Pekka Savola To: Pedro Roque Marques cc: Yakov Rekhter , Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 12:17:53 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, For what it's worth, it seems to me that this memo is a solution looking for the problem. Why do we need this in the first place? To "standardize" commonly used communities? To give the users more tools to mess up their routing, or to allow the users to make the ISP's policy more complex? I'm skeptical about the usefulness of this approach. A few nits: - if EX-COMM doesn't support IPv6 addresses, and that is important enough, the support MUST be added. - it might make sense to switch the order of Length and "ASN" fields for better alignment. Length could also include the ASN field. (Maybe this would be a more typical TLV encoding?) On Wed, 21 Apr 2004, Pedro Roque Marques wrote: > Yakov Rekhter writes: > > Folks, It would be greatly appreciated if folks would read the > > document and comment on it to the IDR mailing list. In other words, > > we need "yes, looks good" or "should fix this and that", not just > > silence. > > my recollection is that this draft has been discussed before and that > the majority of the WG requested that encoding and applications of > communities be kept separate. > > reclying the comments: it does appear that the propossed applications > are possible w/ existing protocol support. The author recognises that > some of those applications may or may not be a good idea given that > they seem to impose on an ISP a set of policies which the ISP may or > may not wish to provide... > > reading the document, it seems that the original comments are still > relevant. > > i also believe that embeding ipv4 and ipv6 addresses into communities is > not a feature... addresses don't make for very good identifiers given > that they may change. > > Pedro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 22 05:40:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14718 for ; Thu, 22 Apr 2004 05:40: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 1BGafF-0005j9-Iy for idr-archive@odin.ietf.org; Thu, 22 Apr 2004 05:38:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M9cbuK022011 for idr-archive@odin.ietf.org; Thu, 22 Apr 2004 05:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGadb-0004qi-VN for idr-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 05:36:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14433 for ; Thu, 22 Apr 2004 05:36:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGadW-0002P7-K9 for idr-web-archive@ietf.org; Thu, 22 Apr 2004 05:36:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGacY-00029o-00 for idr-web-archive@ietf.org; Thu, 22 Apr 2004 05:35:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGabk-0001u6-00; Thu, 22 Apr 2004 05:35:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaPF-0006zD-CQ; Thu, 22 Apr 2004 05:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaN7-0005SH-5j for idr@optimus.ietf.org; Thu, 22 Apr 2004 05:19: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 FAA13806 for ; Thu, 22 Apr 2004 05:19:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaN1-0006Lx-Vc for idr@ietf.org; Thu, 22 Apr 2004 05:19:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaM7-00068s-00 for idr@ietf.org; Thu, 22 Apr 2004 05:18:51 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGaLi-0005vS-00 for idr@ietf.org; Thu, 22 Apr 2004 05:18:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3M9Hr903947; Thu, 22 Apr 2004 12:17:53 +0300 From: Pekka Savola To: Pedro Roque Marques cc: Yakov Rekhter , Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 12:17:53 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, For what it's worth, it seems to me that this memo is a solution looking for the problem. Why do we need this in the first place? To "standardize" commonly used communities? To give the users more tools to mess up their routing, or to allow the users to make the ISP's policy more complex? I'm skeptical about the usefulness of this approach. A few nits: - if EX-COMM doesn't support IPv6 addresses, and that is important enough, the support MUST be added. - it might make sense to switch the order of Length and "ASN" fields for better alignment. Length could also include the ASN field. (Maybe this would be a more typical TLV encoding?) On Wed, 21 Apr 2004, Pedro Roque Marques wrote: > Yakov Rekhter writes: > > Folks, It would be greatly appreciated if folks would read the > > document and comment on it to the IDR mailing list. In other words, > > we need "yes, looks good" or "should fix this and that", not just > > silence. > > my recollection is that this draft has been discussed before and that > the majority of the WG requested that encoding and applications of > communities be kept separate. > > reclying the comments: it does appear that the propossed applications > are possible w/ existing protocol support. The author recognises that > some of those applications may or may not be a good idea given that > they seem to impose on an ISP a set of policies which the ISP may or > may not wish to provide... > > reading the document, it seems that the original comments are still > relevant. > > i also believe that embeding ipv4 and ipv6 addresses into communities is > not a feature... addresses don't make for very good identifiers given > that they may change. > > Pedro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 22 06:01:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15517 for ; Thu, 22 Apr 2004 06:01:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGb1b-0000aN-I1 for idr-archive@ietf.org; Thu, 22 Apr 2004 06:01:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGb0d-0000L7-00 for idr-archive@ietf.org; Thu, 22 Apr 2004 06:00:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGazb-00001M-00; Thu, 22 Apr 2004 05:59:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGauC-0003Kt-8E; Thu, 22 Apr 2004 05:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGanC-0000KG-NO for idr@optimus.ietf.org; Thu, 22 Apr 2004 05:46: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 FAA14962 for ; Thu, 22 Apr 2004 05:46:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGan7-0004tL-83 for idr@ietf.org; Thu, 22 Apr 2004 05:46:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGamG-0004f3-00 for idr@ietf.org; Thu, 22 Apr 2004 05:45:53 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGalN-0004CO-00 for idr@ietf.org; Thu, 22 Apr 2004 05:44:57 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3M9iQW04279; Thu, 22 Apr 2004 12:44:26 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: <200404162121.i3GLLDJ87448@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 12:44:26 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 16 Apr 2004, Yakov Rekhter wrote: > During the Last Call it would be greatly appreciated if folks would > read the document and comment on it to the IDR mailing list. In > other words, we need "yes, looks good" or "should fix this and > that", not just silence. In general, I think this should be rather close to being ready for going forward. A few quick comments: - the text could use a lot more updates, but is readable as it is. - where are the implementation & interop reports? - several ID-nits or other process issues must be fixed, at least: o Status of this memo, Abstract, etc. must be unnumbered sections (typically Introduction is section number 1) o No references in the abstract. o One cannot have normative references to documents of lower maturity level. I suggest moving everything except [1] (or maybe also [7]) to a new Informational References section. o The document should probably say (in Abstract and Introduction) that this document Obsoletes both 2796 and 1966 (note 2796 only Updates 1966, which was probably a bug.)? o Standard IPR statement is needed at the end even if there is is no IPR. The date in the copyright statement is 4 years old as well.. o every empty line in this memo is duplicated (due to flawed DOS/WINDOWS -> Unix conversion?) - food for thought: should we kill two birds in one stone, and also declare RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh routing") historic? Is that useful anymore? - A few rewordings I spotted (I grew bored with the text soon after the abstract, as there would have been a lot of changes): Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. ==> s/Currently in the Internet BGP deployments are configured such that that/Typically/ (the same in the Introduction) information, as is common in many of todays internet networks. ==> s/todays internet/today's Internet/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 22 06:13:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15869 for ; Thu, 22 Apr 2004 06:13:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbBs-00031I-GO for idr-archive@odin.ietf.org; Thu, 22 Apr 2004 06:12:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MACKde011603 for idr-archive@odin.ietf.org; Thu, 22 Apr 2004 06:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGb1i-0006uM-8h for idr-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 06:01: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 GAA15541 for ; Thu, 22 Apr 2004 06:01:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGb1c-0000aY-P8 for idr-web-archive@ietf.org; Thu, 22 Apr 2004 06:01:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGb0e-0000LL-00 for idr-web-archive@ietf.org; Thu, 22 Apr 2004 06:00:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGazb-00001M-00; Thu, 22 Apr 2004 05:59:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGauC-0003Kt-8E; Thu, 22 Apr 2004 05:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGanC-0000KG-NO for idr@optimus.ietf.org; Thu, 22 Apr 2004 05:46: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 FAA14962 for ; Thu, 22 Apr 2004 05:46:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGan7-0004tL-83 for idr@ietf.org; Thu, 22 Apr 2004 05:46:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGamG-0004f3-00 for idr@ietf.org; Thu, 22 Apr 2004 05:45:53 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGalN-0004CO-00 for idr@ietf.org; Thu, 22 Apr 2004 05:44:57 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3M9iQW04279; Thu, 22 Apr 2004 12:44:26 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: <200404162121.i3GLLDJ87448@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 12:44:26 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 16 Apr 2004, Yakov Rekhter wrote: > During the Last Call it would be greatly appreciated if folks would > read the document and comment on it to the IDR mailing list. In > other words, we need "yes, looks good" or "should fix this and > that", not just silence. In general, I think this should be rather close to being ready for going forward. A few quick comments: - the text could use a lot more updates, but is readable as it is. - where are the implementation & interop reports? - several ID-nits or other process issues must be fixed, at least: o Status of this memo, Abstract, etc. must be unnumbered sections (typically Introduction is section number 1) o No references in the abstract. o One cannot have normative references to documents of lower maturity level. I suggest moving everything except [1] (or maybe also [7]) to a new Informational References section. o The document should probably say (in Abstract and Introduction) that this document Obsoletes both 2796 and 1966 (note 2796 only Updates 1966, which was probably a bug.)? o Standard IPR statement is needed at the end even if there is is no IPR. The date in the copyright statement is 4 years old as well.. o every empty line in this memo is duplicated (due to flawed DOS/WINDOWS -> Unix conversion?) - food for thought: should we kill two birds in one stone, and also declare RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh routing") historic? Is that useful anymore? - A few rewordings I spotted (I grew bored with the text soon after the abstract, as there would have been a lot of changes): Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. ==> s/Currently in the Internet BGP deployments are configured such that that/Typically/ (the same in the Introduction) information, as is common in many of todays internet networks. ==> s/todays internet/today's Internet/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 23 01:36:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01292 for ; Fri, 23 Apr 2004 01:36:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGtMp-0004OI-Hg for idr-archive@ietf.org; Fri, 23 Apr 2004 01:36:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGtLr-000473-00 for idr-archive@ietf.org; Fri, 23 Apr 2004 01:35:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGtLP-0003pz-00; Fri, 23 Apr 2004 01:35:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGtBQ-0007nT-I7; Fri, 23 Apr 2004 01:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGt6B-0005kz-Hc for idr@optimus.ietf.org; Fri, 23 Apr 2004 01:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00487 for ; Fri, 23 Apr 2004 01:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGt66-0007Z9-G7 for idr@ietf.org; Fri, 23 Apr 2004 01:19:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGt56-0007HD-00 for idr@ietf.org; Fri, 23 Apr 2004 01:18:33 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGt45-0006kk-00 for idr@ietf.org; Fri, 23 Apr 2004 01:17:29 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3N5Gmf22934; Fri, 23 Apr 2004 08:16:49 +0300 From: Pekka Savola To: Susan Hares cc: Yakov Rekhter , Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 08:16:48 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Apr 2004, Susan Hares wrote: > Can you clarify something here: > 1) Your need - informing the remote peer of > warning limits, stop receive limits, and drop limits > and SNMP traps, logs etcs > > is the basis for the draft. We don't really *need* this, because we're monitoring the number of prefixes advertised by peers. If they go over the top, an alarm sounds in the NOC. There is no need to inform the peer of the prefix limits we use, as no prefixes should be dropped based on that, and if they are, the peer has been badly misbehaving and deserves what it got. Remember, if a peer advertises 100 prefixes, you don't set the prefix limits to 101 prefixes or even 110 prefixes, but probably something like 200 or 500 prefixes. Our threat model here is, "we want to stop peers from accidentally advertising the whole Internet or a lot more routes than is normal to us." I.e., a properly administered systems do not need this option. But I would not object to having a simple option if that's what others see useful. I would object to creating a complex option, because that seems to go too much beyond the cost/benefit curve for an option which is not needed at all in the first place. > 2) Providers we talk to had 2 cases: > > 1) creeping VPN prefix limits > 2) dump of whole routing table > > The need to treat the two differently. No, I think I disagree with this. Why would they have to be treated differently? It's the number of prefixes per peer that counts, not per AFI/SAFI etc. used, or the manner by which they're transmitted. You protect your gear at the edge of the network, from either your peers or your customers (if you import their routes into VPN), so distinguishing per VPN doesn't seem to be all that useful. > 3) Set until changed - that's the rub > > The providers wanted to negotiate the capabilties and > upgrade the capabilities without dropping the connect. > > Is that what you mean as well? If so, could you comment > on what is complex. Currently, adding prefix-limits does not drop a session, so it's required that sessions aren't dropped if the prefix-limits are changed either. That means that if prefix-limit negotiation is specified, it must not require a session reset, yes. > History: > We started this out with capabilities on open, and dynamic > capabilities. Due to some vendor's request to include other > mechanism (ORF, Soft Notify) to support the dynamic features - > we added the rest. > > Other service providers said, Love the function but could you > do it by prefix lengths. > > In an effort to get something working for all these folks, > we made these other features optional. > > What part don't you like? Cause everything you stated you wanted -- > is the basic part of the initial draft? Did you dis-like the additions > (ORF, Soft Notify) and or the optional sub-codes? > > Do you think we should go back to the initial draft simplistic model? It seems to me that if dynamic capabilities is a required-to-implement mechanism, soft-notify is useless or even problematic (what if you are doing both?). Similarly, I fail to see any need for ORF (but admittedly, I haven't looked at it much) or using prefix lengths. Those who would like to distinguish prefix length in the prefix-limiter are probably confusing inbound policy with appropriate prefix-limits. So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and compact to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 23 01:42:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01553 for ; Fri, 23 Apr 2004 01:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGtPc-0003ep-Mn for idr-archive@odin.ietf.org; Fri, 23 Apr 2004 01:39:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N5diUL014059 for idr-archive@odin.ietf.org; Fri, 23 Apr 2004 01:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGtMw-0002mS-Ih for idr-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 01:36:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01322 for ; Fri, 23 Apr 2004 01:36:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGtMr-0004OS-Bx for idr-web-archive@ietf.org; Fri, 23 Apr 2004 01:36:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGtLt-00047I-00 for idr-web-archive@ietf.org; Fri, 23 Apr 2004 01:35:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGtLP-0003pz-00; Fri, 23 Apr 2004 01:35:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGtBQ-0007nT-I7; Fri, 23 Apr 2004 01:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGt6B-0005kz-Hc for idr@optimus.ietf.org; Fri, 23 Apr 2004 01:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00487 for ; Fri, 23 Apr 2004 01:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGt66-0007Z9-G7 for idr@ietf.org; Fri, 23 Apr 2004 01:19:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGt56-0007HD-00 for idr@ietf.org; Fri, 23 Apr 2004 01:18:33 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGt45-0006kk-00 for idr@ietf.org; Fri, 23 Apr 2004 01:17:29 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3N5Gmf22934; Fri, 23 Apr 2004 08:16:49 +0300 From: Pekka Savola To: Susan Hares cc: Yakov Rekhter , Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 08:16:48 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 15 Apr 2004, Susan Hares wrote: > Can you clarify something here: > 1) Your need - informing the remote peer of > warning limits, stop receive limits, and drop limits > and SNMP traps, logs etcs > > is the basis for the draft. We don't really *need* this, because we're monitoring the number of prefixes advertised by peers. If they go over the top, an alarm sounds in the NOC. There is no need to inform the peer of the prefix limits we use, as no prefixes should be dropped based on that, and if they are, the peer has been badly misbehaving and deserves what it got. Remember, if a peer advertises 100 prefixes, you don't set the prefix limits to 101 prefixes or even 110 prefixes, but probably something like 200 or 500 prefixes. Our threat model here is, "we want to stop peers from accidentally advertising the whole Internet or a lot more routes than is normal to us." I.e., a properly administered systems do not need this option. But I would not object to having a simple option if that's what others see useful. I would object to creating a complex option, because that seems to go too much beyond the cost/benefit curve for an option which is not needed at all in the first place. > 2) Providers we talk to had 2 cases: > > 1) creeping VPN prefix limits > 2) dump of whole routing table > > The need to treat the two differently. No, I think I disagree with this. Why would they have to be treated differently? It's the number of prefixes per peer that counts, not per AFI/SAFI etc. used, or the manner by which they're transmitted. You protect your gear at the edge of the network, from either your peers or your customers (if you import their routes into VPN), so distinguishing per VPN doesn't seem to be all that useful. > 3) Set until changed - that's the rub > > The providers wanted to negotiate the capabilties and > upgrade the capabilities without dropping the connect. > > Is that what you mean as well? If so, could you comment > on what is complex. Currently, adding prefix-limits does not drop a session, so it's required that sessions aren't dropped if the prefix-limits are changed either. That means that if prefix-limit negotiation is specified, it must not require a session reset, yes. > History: > We started this out with capabilities on open, and dynamic > capabilities. Due to some vendor's request to include other > mechanism (ORF, Soft Notify) to support the dynamic features - > we added the rest. > > Other service providers said, Love the function but could you > do it by prefix lengths. > > In an effort to get something working for all these folks, > we made these other features optional. > > What part don't you like? Cause everything you stated you wanted -- > is the basic part of the initial draft? Did you dis-like the additions > (ORF, Soft Notify) and or the optional sub-codes? > > Do you think we should go back to the initial draft simplistic model? It seems to me that if dynamic capabilities is a required-to-implement mechanism, soft-notify is useless or even problematic (what if you are doing both?). Similarly, I fail to see any need for ORF (but admittedly, I haven't looked at it much) or using prefix lengths. Those who would like to distinguish prefix length in the prefix-limiter are probably confusing inbound policy with appropriate prefix-limits. So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and compact to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 23 16:27:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08433 for ; Fri, 23 Apr 2004 16:27:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7H6-0005L0-2A for idr-archive@ietf.org; Fri, 23 Apr 2004 16:27:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7G6-0004yk-00 for idr-archive@ietf.org; Fri, 23 Apr 2004 16:26:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7F5-0004dL-00; Fri, 23 Apr 2004 16:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6b2-0003yo-Kc; Fri, 23 Apr 2004 15:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6TU-0000xQ-98 for idr@optimus.ietf.org; Fri, 23 Apr 2004 15:36:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03470; Fri, 23 Apr 2004 15:36:33 -0400 (EDT) Message-Id: <200404231936.PAA03470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-mib-14.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, 23 Apr 2004 15:36:33 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-14.txt Pages : 35 Date : 2004-4-23 This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269. 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. This memo is intended to document deployed implementations of this MIB in a historical context, provide clarifications of some items and also note errors where the MIB fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB with a new one representing the current state of the BGP protocol and its extensions. Distribution of this memo is unlimited. Please forward comments to idr@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-14.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-14.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: <2004-4-23150624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-23150624.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 23 17:11:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12301 for ; Fri, 23 Apr 2004 17:11:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7pv-0006Ck-1w for idr-archive@odin.ietf.org; Fri, 23 Apr 2004 17:03:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NL3pZj023837 for idr-archive@odin.ietf.org; Fri, 23 Apr 2004 17:03:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7H9-0000ff-TJ for idr-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 16:27: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 QAA08462 for ; Fri, 23 Apr 2004 16:27:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7H8-0005LK-79 for idr-web-archive@ietf.org; Fri, 23 Apr 2004 16:27:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7G8-0004yz-00 for idr-web-archive@ietf.org; Fri, 23 Apr 2004 16:26:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7F5-0004dL-00; Fri, 23 Apr 2004 16:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6b2-0003yo-Kc; Fri, 23 Apr 2004 15:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6TU-0000xQ-98 for idr@optimus.ietf.org; Fri, 23 Apr 2004 15:36:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03470; Fri, 23 Apr 2004 15:36:33 -0400 (EDT) Message-Id: <200404231936.PAA03470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-mib-14.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, 23 Apr 2004 15:36:33 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-14.txt Pages : 35 Date : 2004-4-23 This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269. 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. This memo is intended to document deployed implementations of this MIB in a historical context, provide clarifications of some items and also note errors where the MIB fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB with a new one representing the current state of the BGP protocol and its extensions. Distribution of this memo is unlimited. Please forward comments to idr@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-14.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-14.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: <2004-4-23150624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-23150624.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 10:49:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25155 for ; Mon, 26 Apr 2004 10:49:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7Qi-0003tt-Qy for idr-archive@ietf.org; Mon, 26 Apr 2004 10:49:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7Pj-0003oo-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 10:48:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI7Om-0003lb-00; Mon, 26 Apr 2004 10:47:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7G9-0003ky-CN; Mon, 26 Apr 2004 10:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI76a-0000b6-R1 for idr@optimus.ietf.org; Mon, 26 Apr 2004 10:29: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 KAA23965 for ; Mon, 26 Apr 2004 10:29:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI76Y-0002qC-Hs for idr@ietf.org; Mon, 26 Apr 2004 10:29:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI75g-0002lY-00 for idr@ietf.org; Mon, 26 Apr 2004 10:28:12 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BI74P-0002dQ-00 for idr@ietf.org; Mon, 26 Apr 2004 10:26:53 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 40F422D4843 for ; Mon, 26 Apr 2004 10:26:23 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02499-04-21 for ; Mon, 26 Apr 2004 10:26:12 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E4D682D482F for ; Mon, 26 Apr 2004 10:26:11 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3QEQBn12023 for idr@ietf.org; Mon, 26 Apr 2004 10:26:11 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Message-ID: <20040426102611.A11934@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 amavisd-new at nexthop.com Subject: [Idr] [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-idr-bgp4-mib-14.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, 26 Apr 2004 10:26:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Gentles, This document incorporates all last-call comments from Sharon. ----- Forwarded message from 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 : 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-14.txt Pages : 35 Date : 2004-4-23 This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269. [...] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-14.txt ----- End forwarded message ----- -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 10:58:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25551 for ; Mon, 26 Apr 2004 10:58: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 1BI7Tj-0007YH-Rs for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 10:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QEr3JR029026 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 10:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7Qn-0006oj-2H for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 10:50: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 KAA25187 for ; Mon, 26 Apr 2004 10:49:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7Qk-0003u5-Ko for idr-web-archive@ietf.org; Mon, 26 Apr 2004 10:49:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7Pk-0003p2-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 10:48:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI7Om-0003lb-00; Mon, 26 Apr 2004 10:47:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7G9-0003ky-CN; Mon, 26 Apr 2004 10:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI76a-0000b6-R1 for idr@optimus.ietf.org; Mon, 26 Apr 2004 10:29: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 KAA23965 for ; Mon, 26 Apr 2004 10:29:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI76Y-0002qC-Hs for idr@ietf.org; Mon, 26 Apr 2004 10:29:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI75g-0002lY-00 for idr@ietf.org; Mon, 26 Apr 2004 10:28:12 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BI74P-0002dQ-00 for idr@ietf.org; Mon, 26 Apr 2004 10:26:53 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 40F422D4843 for ; Mon, 26 Apr 2004 10:26:23 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02499-04-21 for ; Mon, 26 Apr 2004 10:26:12 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E4D682D482F for ; Mon, 26 Apr 2004 10:26:11 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3QEQBn12023 for idr@ietf.org; Mon, 26 Apr 2004 10:26:11 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Message-ID: <20040426102611.A11934@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 amavisd-new at nexthop.com Subject: [Idr] [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-idr-bgp4-mib-14.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, 26 Apr 2004 10:26:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Gentles, This document incorporates all last-call comments from Sharon. ----- Forwarded message from 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 : 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-14.txt Pages : 35 Date : 2004-4-23 This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269. [...] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-14.txt ----- End forwarded message ----- -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 11:29:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27206 for ; Mon, 26 Apr 2004 11:29:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI83H-0006TX-DV for idr-archive@ietf.org; Mon, 26 Apr 2004 11:29:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI822-0006Lu-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 11:28:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI81J-0006Dq-00; Mon, 26 Apr 2004 11:27:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7q1-00059Z-8t; Mon, 26 Apr 2004 11:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7eK-0001ao-4G for idr@optimus.ietf.org; Mon, 26 Apr 2004 11:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25811 for ; Mon, 26 Apr 2004 11:03:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7eH-0004kW-IR for idr@ietf.org; Mon, 26 Apr 2004 11:03:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7dO-0004iA-00 for idr@ietf.org; Mon, 26 Apr 2004 11:03:02 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BI7cZ-0004bp-00 for idr@ietf.org; Mon, 26 Apr 2004 11:02:12 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3QF1fl61598 for ; Mon, 26 Apr 2004 08:01:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3QF1aJ01072 for ; Mon, 26 Apr 2004 08:01:36 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404261501.i3QF1aJ01072@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22294.1082991696.1@juniper.net> From: Yakov Rekhter Subject: [Idr] Soft-Notify as an IDR WG document 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, 26 Apr 2004 08:01:36 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Please comment on the attached. The deadline for comments is May 10. Yakov. ------- Forwarded Message Date: Tue, 20 Apr 2004 12:47:27 -0700 From: Gargi Nalawade To: idr@ietf.org Subject: [Idr] Soft-Notify as IDR WG document Hi All, I would like to request that BGP Soft-Notify draft, draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG document. - -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 11:42:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28060 for ; Mon, 26 Apr 2004 11:42: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 1BI8Bd-0004R0-UD for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 11:38:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFcPTv017038 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 11:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI83J-0001eY-Ka for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 11:29: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 LAA27232 for ; Mon, 26 Apr 2004 11:29:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI83I-0006Tk-N0 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 11:29:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI824-0006M8-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 11:28:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI81J-0006Dq-00; Mon, 26 Apr 2004 11:27:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7q1-00059Z-8t; Mon, 26 Apr 2004 11:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7eK-0001ao-4G for idr@optimus.ietf.org; Mon, 26 Apr 2004 11:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25811 for ; Mon, 26 Apr 2004 11:03:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7eH-0004kW-IR for idr@ietf.org; Mon, 26 Apr 2004 11:03:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7dO-0004iA-00 for idr@ietf.org; Mon, 26 Apr 2004 11:03:02 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BI7cZ-0004bp-00 for idr@ietf.org; Mon, 26 Apr 2004 11:02:12 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3QF1fl61598 for ; Mon, 26 Apr 2004 08:01:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3QF1aJ01072 for ; Mon, 26 Apr 2004 08:01:36 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404261501.i3QF1aJ01072@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22294.1082991696.1@juniper.net> From: Yakov Rekhter Subject: [Idr] Soft-Notify as an IDR WG document 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, 26 Apr 2004 08:01:36 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Please comment on the attached. The deadline for comments is May 10. Yakov. ------- Forwarded Message Date: Tue, 20 Apr 2004 12:47:27 -0700 From: Gargi Nalawade To: idr@ietf.org Subject: [Idr] Soft-Notify as IDR WG document Hi All, I would like to request that BGP Soft-Notify draft, draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG document. - -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 12:33:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01002 for ; Mon, 26 Apr 2004 12:33:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI93S-0003aM-1Z for idr-archive@ietf.org; Mon, 26 Apr 2004 12:34:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI92W-0003Wr-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 12:33:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI91e-0003Tz-00; Mon, 26 Apr 2004 12:32:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8sn-0002QM-5N; Mon, 26 Apr 2004 12: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 1BFwq8-0004VR-0x for idr@optimus.ietf.org; Tue, 20 Apr 2004 11:07: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 LAA24120 for ; Tue, 20 Apr 2004 11:07:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwq5-0004ER-8x for idr@ietf.org; Tue, 20 Apr 2004 11:07:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwp2-0003vn-00 for idr@ietf.org; Tue, 20 Apr 2004 11:06:04 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 1BFwo0-0003aJ-00 for idr@ietf.org; Tue, 20 Apr 2004 11:05:00 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 169DC4FC51; Tue, 20 Apr 2004 11:04:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16517.15372.723230.469986@durmstrang.padfoot.com> From: Henry Kilmer To: "John G. Scudder" Cc: idr@ietf.org Subject: [Idr] Multisession as WG doc In-Reply-To: References: X-Mailer: VM 7.17 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid 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, 20 Apr 2004 11:04:44 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit John G. Scudder writes: >Hi Folks, > >I'd like to suggest that Multisession BGP >(draft-scudder-bgp-multisession-00.txt) be considered as an IDR >working group document. This document should definately be a WG document. -Hank _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 12:54:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02124 for ; Mon, 26 Apr 2004 12:54: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 1BI99T-0000Yx-HZ for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGeF1q002152 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI93U-0006U3-Uq for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:34:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01026 for ; Mon, 26 Apr 2004 12:34:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI93T-0003aW-A5 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 12:34:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI92X-0003X5-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 12:33:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI91e-0003Tz-00; Mon, 26 Apr 2004 12:32:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8sn-0002QM-5N; Mon, 26 Apr 2004 12: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 1BFwq8-0004VR-0x for idr@optimus.ietf.org; Tue, 20 Apr 2004 11:07: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 LAA24120 for ; Tue, 20 Apr 2004 11:07:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwq5-0004ER-8x for idr@ietf.org; Tue, 20 Apr 2004 11:07:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwp2-0003vn-00 for idr@ietf.org; Tue, 20 Apr 2004 11:06:04 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 1BFwo0-0003aJ-00 for idr@ietf.org; Tue, 20 Apr 2004 11:05:00 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 169DC4FC51; Tue, 20 Apr 2004 11:04:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16517.15372.723230.469986@durmstrang.padfoot.com> From: Henry Kilmer To: "John G. Scudder" Cc: idr@ietf.org Subject: [Idr] Multisession as WG doc In-Reply-To: References: X-Mailer: VM 7.17 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid 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, 20 Apr 2004 11:04:44 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John G. Scudder writes: >Hi Folks, > >I'd like to suggest that Multisession BGP >(draft-scudder-bgp-multisession-00.txt) be considered as an IDR >working group document. This document should definately be a WG document. -Hank _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 13:20:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04103 for ; Mon, 26 Apr 2004 13:20:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9m8-0007QD-OL for idr-archive@ietf.org; Mon, 26 Apr 2004 13:20:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9lI-0007MD-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 13:19:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9kl-0007HJ-00; Mon, 26 Apr 2004 13:18:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9h7-0002zf-Jy; Mon, 26 Apr 2004 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9YU-00006T-7W for idr@optimus.ietf.org; Mon, 26 Apr 2004 13:06: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 NAA03065 for ; Mon, 26 Apr 2004 13:06:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9YS-0006HF-9y for idr@ietf.org; Mon, 26 Apr 2004 13:06:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Xe-0006Dh-00 for idr@ietf.org; Mon, 26 Apr 2004 13:05:15 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BI9X5-00068u-00 for idr@ietf.org; Mon, 26 Apr 2004 13:04:39 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QH495O019763; Mon, 26 Apr 2004 10:04:09 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QH49xC019760; Mon, 26 Apr 2004 10:04:09 -0700 (PDT) Message-Id: <200404261704.i3QH49xC019760@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 10:04:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > Folks, Please comment on the attached. The deadline for comments is > May 10. I dont think this document should be accepted as a work-group document. The unit of containment in bgp should be the session. We can possibly have multiple sessions between a pair of systems either via manual config or with the mecanism that Scudder is proposing. Attempting to reset a subset of the nlri is something that won't work in a considerable number of cases and that adds a very significant ammount of complexity to BGP. I would like to propose that the WG rejects this approach. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 13:44:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05223 for ; Mon, 26 Apr 2004 13:44: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 1BI9wT-0008Jo-Df for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 13:30:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHUrXT031972 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 13:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9mC-0004kb-4f for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 13:20: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 NAA04130 for ; Mon, 26 Apr 2004 13:20:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9mA-0007QP-6e for idr-web-archive@ietf.org; Mon, 26 Apr 2004 13:20:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9lJ-0007MR-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 13:19:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9kl-0007HJ-00; Mon, 26 Apr 2004 13:18:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9h7-0002zf-Jy; Mon, 26 Apr 2004 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9YU-00006T-7W for idr@optimus.ietf.org; Mon, 26 Apr 2004 13:06: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 NAA03065 for ; Mon, 26 Apr 2004 13:06:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9YS-0006HF-9y for idr@ietf.org; Mon, 26 Apr 2004 13:06:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Xe-0006Dh-00 for idr@ietf.org; Mon, 26 Apr 2004 13:05:15 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BI9X5-00068u-00 for idr@ietf.org; Mon, 26 Apr 2004 13:04:39 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QH495O019763; Mon, 26 Apr 2004 10:04:09 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QH49xC019760; Mon, 26 Apr 2004 10:04:09 -0700 (PDT) Message-Id: <200404261704.i3QH49xC019760@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 10:04:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > Folks, Please comment on the attached. The deadline for comments is > May 10. I dont think this document should be accepted as a work-group document. The unit of containment in bgp should be the session. We can possibly have multiple sessions between a pair of systems either via manual config or with the mecanism that Scudder is proposing. Attempting to reset a subset of the nlri is something that won't work in a considerable number of cases and that adds a very significant ammount of complexity to BGP. I would like to propose that the WG rejects this approach. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 14:22:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07651 for ; Mon, 26 Apr 2004 14:22:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAki-0004PV-5y for idr-archive@ietf.org; Mon, 26 Apr 2004 14:22:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAjC-0004Bf-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 14:21:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIAhN-0003po-00; Mon, 26 Apr 2004 14:19:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAUW-0006BC-AM; Mon, 26 Apr 2004 14:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAKy-0002ml-IC for idr@optimus.ietf.org; Mon, 26 Apr 2004 13:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05894 for ; Mon, 26 Apr 2004 13:56:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAKw-0001yM-BO for idr@ietf.org; Mon, 26 Apr 2004 13:56:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAJz-0001ul-00 for idr@ietf.org; Mon, 26 Apr 2004 13:55:12 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAJH-0001ok-00 for idr@ietf.org; Mon, 26 Apr 2004 13:54:27 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0A7EB2D482F for ; Mon, 26 Apr 2004 13:53:57 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08652-01-2 for ; Mon, 26 Apr 2004 13:53:44 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 015CF2D4856 for ; Mon, 26 Apr 2004 13:53:44 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQo8jzx/1yEIpStQGC+uslHUvVWcQCxPDag From: "Susan Hares" To: "Pekka Savola" Cc: "Yakov Rekhter" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 13:53:43 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Pekka: Thanks for the input. Your vote is for=20 the simple version.=20 Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Friday, April 23, 2004 1:17 AM To: Susan Hares Cc: Yakov Rekhter; idr@ietf.org Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document On Thu, 15 Apr 2004, Susan Hares wrote: > Can you clarify something here: > 1) Your need - informing the remote peer of > warning limits, stop receive limits, and drop limits > and SNMP traps, logs etcs >=20 > is the basis for the draft. We don't really *need* this, because we're monitoring the number of prefixes advertised by peers. If they go over the top, an alarm sounds in the NOC. There is no need to inform the peer of the prefix limits we use, as no prefixes should be dropped based on that, and if they are, the peer has been badly misbehaving and deserves what it got. Remember, if a peer advertises 100 prefixes, you don't set the prefix=20 limits to 101 prefixes or even 110 prefixes, but probably something=20 like 200 or 500 prefixes. Our threat model here is, "we want to stop peers from accidentally advertising the whole Internet or a lot more routes than is normal to us." I.e., a properly administered systems do not need this option. But I would not object to having a simple option if that's what others see useful. I would object to creating a complex option, because that seems to go too much beyond the cost/benefit curve for an option which is not needed at all in the first place. > 2) Providers we talk to had 2 cases: > =09 > 1) creeping VPN prefix limits > 2) dump of whole routing table >=20 > The need to treat the two differently. No, I think I disagree with this. Why would they have to be treated=20 differently? It's the number of prefixes per peer that counts, not=20 per AFI/SAFI etc. used, or the manner by which they're transmitted. You protect your gear at the edge of the network, from either your peers or your customers (if you import their routes into VPN), so distinguishing per VPN doesn't seem to be all that useful. > 3) Set until changed - that's the rub >=20 > The providers wanted to negotiate the capabilties and > upgrade the capabilities without dropping the connect. >=20 > Is that what you mean as well? If so, could you comment > on what is complex. Currently, adding prefix-limits does not drop a session, so it's=20 required that sessions aren't dropped if the prefix-limits are changed=20 either. That means that if prefix-limit negotiation is specified, it=20 must not require a session reset, yes. =20 > History:=20 > We started this out with capabilities on open, and dynamic > capabilities. Due to some vendor's request to include other > mechanism (ORF, Soft Notify) to support the dynamic features -=20 > we added the rest. >=20 > Other service providers said, Love the function but could you > do it by prefix lengths. =20 >=20 > In an effort to get something working for all these folks, > we made these other features optional. =20 >=20 > What part don't you like? Cause everything you stated you wanted -- > is the basic part of the initial draft? Did you dis-like the = additions > (ORF, Soft Notify) and or the optional sub-codes?=20 > > Do you think we should go back to the initial draft simplistic model? It seems to me that if dynamic capabilities is a required-to-implement mechanism, soft-notify is useless or even problematic (what if you are doing both?). Similarly, I fail to see any need for ORF (but admittedly, I haven't looked at it much) or using prefix lengths. =20 Those who would like to distinguish prefix length in the prefix-limiter are probably confusing inbound policy with appropriate prefix-limits. So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and=20 compact to me. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 14:40:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09132 for ; Mon, 26 Apr 2004 14:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAuF-00060l-Ot for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 14:32:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIWdbj023107 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 14:32:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAkm-0003Mk-4M for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 14:22:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07677 for ; Mon, 26 Apr 2004 14:22:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAkj-0004Pf-KA for idr-web-archive@ietf.org; Mon, 26 Apr 2004 14:22:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAjE-0004Bu-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 14:21:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIAhN-0003po-00; Mon, 26 Apr 2004 14:19:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAUW-0006BC-AM; Mon, 26 Apr 2004 14:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAKy-0002ml-IC for idr@optimus.ietf.org; Mon, 26 Apr 2004 13:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05894 for ; Mon, 26 Apr 2004 13:56:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAKw-0001yM-BO for idr@ietf.org; Mon, 26 Apr 2004 13:56:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAJz-0001ul-00 for idr@ietf.org; Mon, 26 Apr 2004 13:55:12 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAJH-0001ok-00 for idr@ietf.org; Mon, 26 Apr 2004 13:54:27 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0A7EB2D482F for ; Mon, 26 Apr 2004 13:53:57 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08652-01-2 for ; Mon, 26 Apr 2004 13:53:44 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 015CF2D4856 for ; Mon, 26 Apr 2004 13:53:44 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQo8jzx/1yEIpStQGC+uslHUvVWcQCxPDag From: "Susan Hares" To: "Pekka Savola" Cc: "Yakov Rekhter" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 13:53:43 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka: Thanks for the input. Your vote is for=20 the simple version.=20 Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Friday, April 23, 2004 1:17 AM To: Susan Hares Cc: Yakov Rekhter; idr@ietf.org Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document On Thu, 15 Apr 2004, Susan Hares wrote: > Can you clarify something here: > 1) Your need - informing the remote peer of > warning limits, stop receive limits, and drop limits > and SNMP traps, logs etcs >=20 > is the basis for the draft. We don't really *need* this, because we're monitoring the number of prefixes advertised by peers. If they go over the top, an alarm sounds in the NOC. There is no need to inform the peer of the prefix limits we use, as no prefixes should be dropped based on that, and if they are, the peer has been badly misbehaving and deserves what it got. Remember, if a peer advertises 100 prefixes, you don't set the prefix=20 limits to 101 prefixes or even 110 prefixes, but probably something=20 like 200 or 500 prefixes. Our threat model here is, "we want to stop peers from accidentally advertising the whole Internet or a lot more routes than is normal to us." I.e., a properly administered systems do not need this option. But I would not object to having a simple option if that's what others see useful. I would object to creating a complex option, because that seems to go too much beyond the cost/benefit curve for an option which is not needed at all in the first place. > 2) Providers we talk to had 2 cases: > =09 > 1) creeping VPN prefix limits > 2) dump of whole routing table >=20 > The need to treat the two differently. No, I think I disagree with this. Why would they have to be treated=20 differently? It's the number of prefixes per peer that counts, not=20 per AFI/SAFI etc. used, or the manner by which they're transmitted. You protect your gear at the edge of the network, from either your peers or your customers (if you import their routes into VPN), so distinguishing per VPN doesn't seem to be all that useful. > 3) Set until changed - that's the rub >=20 > The providers wanted to negotiate the capabilties and > upgrade the capabilities without dropping the connect. >=20 > Is that what you mean as well? If so, could you comment > on what is complex. Currently, adding prefix-limits does not drop a session, so it's=20 required that sessions aren't dropped if the prefix-limits are changed=20 either. That means that if prefix-limit negotiation is specified, it=20 must not require a session reset, yes. =20 > History:=20 > We started this out with capabilities on open, and dynamic > capabilities. Due to some vendor's request to include other > mechanism (ORF, Soft Notify) to support the dynamic features -=20 > we added the rest. >=20 > Other service providers said, Love the function but could you > do it by prefix lengths. =20 >=20 > In an effort to get something working for all these folks, > we made these other features optional. =20 >=20 > What part don't you like? Cause everything you stated you wanted -- > is the basic part of the initial draft? Did you dis-like the = additions > (ORF, Soft Notify) and or the optional sub-codes?=20 > > Do you think we should go back to the initial draft simplistic model? It seems to me that if dynamic capabilities is a required-to-implement mechanism, soft-notify is useless or even problematic (what if you are doing both?). Similarly, I fail to see any need for ORF (but admittedly, I haven't looked at it much) or using prefix lengths. =20 Those who would like to distinguish prefix length in the prefix-limiter are probably confusing inbound policy with appropriate prefix-limits. So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and=20 compact to me. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 15:01:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10524 for ; Mon, 26 Apr 2004 15:01:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBLl-0007VW-KS for idr-archive@ietf.org; Mon, 26 Apr 2004 15:01:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBKr-0007Ov-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 15:00:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBJI-0007KI-00; Mon, 26 Apr 2004 14:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIB8B-0001CL-UE; Mon, 26 Apr 2004 14:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIB2O-0008E0-Eu for idr@optimus.ietf.org; Mon, 26 Apr 2004 14:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09179 for ; Mon, 26 Apr 2004 14:41:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIB2L-0005x2-MZ for idr@ietf.org; Mon, 26 Apr 2004 14:41:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIB1R-0005sI-00 for idr@ietf.org; Mon, 26 Apr 2004 14:40:05 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BIB0W-0005lr-00 for idr@ietf.org; Mon, 26 Apr 2004 14:39:08 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3QIccl62501 for ; Mon, 26 Apr 2004 11:38:38 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3QIcXJ30288; Mon, 26 Apr 2004 11:38:33 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i3QIcX859341; Mon, 26 Apr 2004 11:38:33 -0700 (PDT) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs From: Rahul Aggarwal To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> Message-ID: <20040426112015.I53161@sapphire.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> 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: Mon, 26 Apr 2004 11:38:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 26 Apr 2004, Yakov Rekhter wrote: > Folks, > > Please comment on the attached. The deadline for comments is > May 10. > I don't think this document should be accepted as a WG document. Resetting some of the nlris on the same session will not help in a several cases and adds complexity. Also such an attempt at partial recovery may lead to the session continuing to operate in a faulty/corrupted state. rahul > Yakov. > > ------- Forwarded Message > > Date: Tue, 20 Apr 2004 12:47:27 -0700 > From: Gargi Nalawade > To: idr@ietf.org > Subject: [Idr] Soft-Notify as IDR WG document > > Hi All, > > I would like to request that BGP Soft-Notify draft, > draft-nalawade-bgp-soft-notify-00.txt be accepted as > an IDR WG document. > > - -Gargi > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > > _______________________________________________ > 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 Mon Apr 26 15:19:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12785 for ; Mon, 26 Apr 2004 15:19:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBZG-0005YW-R7 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 15:15:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QJF2wg021350 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 15:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBLq-0005Au-GV for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 15:01: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 PAA10550 for ; Mon, 26 Apr 2004 15:01:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBLn-0007Vm-K3 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:01:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBKu-0007PK-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:00:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBJI-0007KI-00; Mon, 26 Apr 2004 14:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIB8B-0001CL-UE; Mon, 26 Apr 2004 14:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIB2O-0008E0-Eu for idr@optimus.ietf.org; Mon, 26 Apr 2004 14:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09179 for ; Mon, 26 Apr 2004 14:41:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIB2L-0005x2-MZ for idr@ietf.org; Mon, 26 Apr 2004 14:41:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIB1R-0005sI-00 for idr@ietf.org; Mon, 26 Apr 2004 14:40:05 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BIB0W-0005lr-00 for idr@ietf.org; Mon, 26 Apr 2004 14:39:08 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3QIccl62501 for ; Mon, 26 Apr 2004 11:38:38 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3QIcXJ30288; Mon, 26 Apr 2004 11:38:33 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i3QIcX859341; Mon, 26 Apr 2004 11:38:33 -0700 (PDT) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs From: Rahul Aggarwal To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> Message-ID: <20040426112015.I53161@sapphire.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> 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: Mon, 26 Apr 2004 11:38:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 26 Apr 2004, Yakov Rekhter wrote: > Folks, > > Please comment on the attached. The deadline for comments is > May 10. > I don't think this document should be accepted as a WG document. Resetting some of the nlris on the same session will not help in a several cases and adds complexity. Also such an attempt at partial recovery may lead to the session continuing to operate in a faulty/corrupted state. rahul > Yakov. > > ------- Forwarded Message > > Date: Tue, 20 Apr 2004 12:47:27 -0700 > From: Gargi Nalawade > To: idr@ietf.org > Subject: [Idr] Soft-Notify as IDR WG document > > Hi All, > > I would like to request that BGP Soft-Notify draft, > draft-nalawade-bgp-soft-notify-00.txt be accepted as > an IDR WG document. > > - -Gargi > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 15:28:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13343 for ; Mon, 26 Apr 2004 15:28:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBlu-000176-8S for idr-archive@ietf.org; Mon, 26 Apr 2004 15:28:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBl3-00014u-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 15:27:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBkd-00012j-00; Mon, 26 Apr 2004 15:26:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBd7-0006iv-Da; Mon, 26 Apr 2004 15:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBWa-0004Hk-31 for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:12: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 PAA11752 for ; Mon, 26 Apr 2004 15:12:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBWY-0000D8-SK for idr@ietf.org; Mon, 26 Apr 2004 15:12:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBVj-0000BC-00 for idr@ietf.org; Mon, 26 Apr 2004 15:11:24 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BIBVF-00008Y-00 for idr@ietf.org; Mon, 26 Apr 2004 15:10:53 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 37D29798E6C; Mon, 26 Apr 2004 12:10:53 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17966-07; Mon, 26 Apr 2004 12:10:52 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 585EA798E6A; Mon, 26 Apr 2004 12:10:52 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 8FA6A979C2; Mon, 26 Apr 2004 12:10:51 -0700 (PDT) To: "Susan Hares" Cc: "Pekka Savola" , enke@redback.com, "Yakov Rekhter" , idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message from "Susan Hares" of "Mon, 26 Apr 2004 13:53:43 EDT." From: Enke Chen Message-Id: <20040426191051.8FA6A979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 12:10:51 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Sue: At the last IDR meeting, there were several suggestions about simplifying the spec.. One particular one (by jgs?) is to just advertise the prefix limit, something like . As a BGP speaker knows how many prefixes it has advertised to a particular peer, the received from a peer should be sufficient for a local BGP to take action (such as generate warning, stop advertisement, ...) *If* the prefix-limit advertisement is needed, I suggest that we take the approach of just advertising . The current draft is just too complicated for the feature. -- Enke > From: "Susan Hares" > To: "Pekka Savola" > Cc: "Yakov Rekhter" , > > > Pekka: > > Thanks for the input. Your vote is for=20 > the simple version.=20 > > Sue > > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, April 23, 2004 1:17 AM > To: Susan Hares > Cc: Yakov Rekhter; idr@ietf.org > Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > > On Thu, 15 Apr 2004, Susan Hares wrote: > > Can you clarify something here: > > 1) Your need - informing the remote peer of > > warning limits, stop receive limits, and drop limits > > and SNMP traps, logs etcs > >=20 > > is the basis for the draft. > > We don't really *need* this, because we're monitoring the number of > prefixes advertised by peers. If they go over the top, an alarm > sounds in the NOC. There is no need to inform the peer of the prefix > limits we use, as no prefixes should be dropped based on that, and if > they are, the peer has been badly misbehaving and deserves what it > got. > > Remember, if a peer advertises 100 prefixes, you don't set the prefix=20 > limits to 101 prefixes or even 110 prefixes, but probably something=20 > like 200 or 500 prefixes. > > Our threat model here is, "we want to stop peers from accidentally > advertising the whole Internet or a lot more routes than is normal to > us." > > I.e., a properly administered systems do not need this option. > > But I would not object to having a simple option if that's what others > see useful. I would object to creating a complex option, because that > seems to go too much beyond the cost/benefit curve for an option which > is not needed at all in the first place. > > > 2) Providers we talk to had 2 cases: > > =09 > > 1) creeping VPN prefix limits > > 2) dump of whole routing table > >=20 > > The need to treat the two differently. > > No, I think I disagree with this. Why would they have to be treated=20 > differently? It's the number of prefixes per peer that counts, not=20 > per AFI/SAFI etc. used, or the manner by which they're transmitted. > > You protect your gear at the edge of the network, from either your > peers or your customers (if you import their routes into VPN), so > distinguishing per VPN doesn't seem to be all that useful. > > > 3) Set until changed - that's the rub > >=20 > > The providers wanted to negotiate the capabilties and > > upgrade the capabilities without dropping the connect. > >=20 > > Is that what you mean as well? If so, could you comment > > on what is complex. > > Currently, adding prefix-limits does not drop a session, so it's=20 > required that sessions aren't dropped if the prefix-limits are changed=20 > either. That means that if prefix-limit negotiation is specified, it=20 > must not require a session reset, yes. > =20 > > History:=20 > > We started this out with capabilities on open, and dynamic > > capabilities. Due to some vendor's request to include other > > mechanism (ORF, Soft Notify) to support the dynamic features -=20 > > we added the rest. > >=20 > > Other service providers said, Love the function but could you > > do it by prefix lengths. =20 > >=20 > > In an effort to get something working for all these folks, > > we made these other features optional. =20 > >=20 > > What part don't you like? Cause everything you stated you wanted -- > > is the basic part of the initial draft? Did you dis-like the = > additions > > (ORF, Soft Notify) and or the optional sub-codes?=20 > > > > Do you think we should go back to the initial draft simplistic model? > > It seems to me that if dynamic capabilities is a required-to-implement > mechanism, soft-notify is useless or even problematic (what if you are > doing both?). Similarly, I fail to see any need for ORF (but > admittedly, I haven't looked at it much) or using prefix lengths. =20 > Those who would like to distinguish prefix length in the > prefix-limiter are probably confusing inbound policy with appropriate > prefix-limits. > > So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and=20 > compact to me. > > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 15:33:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13816 for ; Mon, 26 Apr 2004 15:33:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBqz-0001PP-7I for idr-archive@ietf.org; Mon, 26 Apr 2004 15:33:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBq2-0001Lq-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 15:32:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBpM-0001I5-00; Mon, 26 Apr 2004 15:31:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBju-0008Ed-St; Mon, 26 Apr 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBaZ-000601-5K for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:16:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12253 for ; Mon, 26 Apr 2004 15:16:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBaX-0000Sx-PN for idr@ietf.org; Mon, 26 Apr 2004 15:16:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBZe-0000OQ-00 for idr@ietf.org; Mon, 26 Apr 2004 15:15:26 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1BIBYr-0000Hj-00 for idr@ietf.org; Mon, 26 Apr 2004 15:14:37 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QJE5Dm011281; Mon, 26 Apr 2004 14:14:06 -0500 (CDT) From: Andrew Lange To: Pedro Roque Marques , Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <2671110.1082981630@[192.168.5.191]> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 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: Mon, 26 Apr 2004 12:13:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Pedro, Replies are inline. > my recollection is that this draft has been discussed before and that > the majority of the WG requested that encoding and applications of > communities be kept separate. This suggestion was brought up at the SF IETF meeting. There was no action taken to access if this was a majority opinion or not. If we look at the former communities documents (1997 or the ext-comms draft) an initial set of applications is also specified in those documents. The applications specified in this draft parallel the ones specified in 1997 and ext-comms, with a couple of additions (neighbor classes, prepend, announce_with). > reclying the comments: it does appear that the propossed applications > are possible w/ existing protocol support. The author recognises that > some of those applications may or may not be a good idea given that > they seem to impose on an ISP a set of policies which the ISP may or > may not wish to provide... > > reading the document, it seems that the original comments are still > relevant. Could you expand on this a little? As an operator at the time I wrote this, I included a proviso that says that operators MUST be able to turn things off that they do not wish to honor. The application that I think SPs will be cautious with is the ANNOUNCE_WITH option. Some providers will want to allow their customers to do this, but some may not. The basis for this proposal was community policies that providers were already painstakingly using in their networks. The policy actions in the flex comms draft makes those policies easier to express, implement and maintain in SP's networks. Examples would include easy sending of lists of ASNs for NO_EXPORT, neighbor-class functionality, etc. > i also believe that embeding ipv4 and ipv6 addresses into communities is > not a feature... addresses don't make for very good identifiers given > that they may change. Changing addresses can be an operational concern. However, this extends the options that exist for extended communities. You cannot send a IPv6 route-target without the ability to encode an IP address. There are also some tactical situations where a BGP-savvy customer would want to encode an IP address. For example one could wish to prepend to an east-coast peer for its routes to avoid a perceived problem on that peering link. So AS 100 ---- AS 200 ---- AS 100 | AS 5000 AS 5000 would announce to 200 a community where it would ask that a specific prefix or set of prefixes be prepended to AS 100's east-coast peer IP (or neighbor class, if those are configured). AS 200 would prepend, and some of the traffic would move over to the AS100-AS200 west coast link. Andrew _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 15:40:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14385 for ; Mon, 26 Apr 2004 15:40:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBxv-0001tF-So for idr-archive@ietf.org; Mon, 26 Apr 2004 15:40:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBwi-0001o2-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 15:39:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBvW-0001ht-00; Mon, 26 Apr 2004 15:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBpi-0000YG-T4; Mon, 26 Apr 2004 15:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBj1-000832-NN for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:25:07 -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 PAA13092 for ; Mon, 26 Apr 2004 15:25:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBj0-0000xN-EH for idr@ietf.org; Mon, 26 Apr 2004 15:25:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBi4-0000va-00 for idr@ietf.org; Mon, 26 Apr 2004 15:24:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BIBhR-0000ru-00 for idr@ietf.org; Mon, 26 Apr 2004 15:23:29 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2004 12:23:00 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-33.cisco.com [10.86.242.33]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3QJMvYu022232; Mon, 26 Apr 2004 15:22:57 -0400 (EDT) From: "zafar ali" To: "'Yakov Rekhter'" , Subject: RE: [Idr] Soft-Notify as an IDR WG document Organization: Cisco Systems Message-ID: <000401c42bc3$e2045b90$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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, 26 Apr 2004 15:22:57 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, Yes, this document should be accepted as a WG ID. Thanks Regards... Zafar >-----Original Message----- >From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf >Of Yakov Rekhter >Sent: Monday, April 26, 2004 11:02 AM >To: idr@ietf.org >Subject: [Idr] Soft-Notify as an IDR WG document > > >Folks, > >Please comment on the attached. The deadline for comments is May 10. > >Yakov. > >------- Forwarded Message > >Date: Tue, 20 Apr 2004 12:47:27 -0700 >From: Gargi Nalawade >To: idr@ietf.org >Subject: [Idr] Soft-Notify as IDR WG document > >Hi All, > >I would like to request that BGP Soft-Notify draft, >draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG >document. > >- -Gargi > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > >------- End of Forwarded Message > > >_______________________________________________ >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 Mon Apr 26 16:38:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16901 for ; Mon, 26 Apr 2004 16:38:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBsW-00010B-Hw for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 15:34:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QJYuuf003846 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 15:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBlx-0008QW-1v for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 15:28: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 PAA13369 for ; Mon, 26 Apr 2004 15:28:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBlv-00017G-NR for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:28:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBl5-000158-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:27:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBkd-00012j-00; Mon, 26 Apr 2004 15:26:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBd7-0006iv-Da; Mon, 26 Apr 2004 15:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBWa-0004Hk-31 for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:12: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 PAA11752 for ; Mon, 26 Apr 2004 15:12:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBWY-0000D8-SK for idr@ietf.org; Mon, 26 Apr 2004 15:12:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBVj-0000BC-00 for idr@ietf.org; Mon, 26 Apr 2004 15:11:24 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BIBVF-00008Y-00 for idr@ietf.org; Mon, 26 Apr 2004 15:10:53 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 37D29798E6C; Mon, 26 Apr 2004 12:10:53 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17966-07; Mon, 26 Apr 2004 12:10:52 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 585EA798E6A; Mon, 26 Apr 2004 12:10:52 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 8FA6A979C2; Mon, 26 Apr 2004 12:10:51 -0700 (PDT) To: "Susan Hares" Cc: "Pekka Savola" , enke@redback.com, "Yakov Rekhter" , idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message from "Susan Hares" of "Mon, 26 Apr 2004 13:53:43 EDT." From: Enke Chen Message-Id: <20040426191051.8FA6A979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 12:10:51 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Sue: At the last IDR meeting, there were several suggestions about simplifying the spec.. One particular one (by jgs?) is to just advertise the prefix limit, something like . As a BGP speaker knows how many prefixes it has advertised to a particular peer, the received from a peer should be sufficient for a local BGP to take action (such as generate warning, stop advertisement, ...) *If* the prefix-limit advertisement is needed, I suggest that we take the approach of just advertising . The current draft is just too complicated for the feature. -- Enke > From: "Susan Hares" > To: "Pekka Savola" > Cc: "Yakov Rekhter" , > > > Pekka: > > Thanks for the input. Your vote is for=20 > the simple version.=20 > > Sue > > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, April 23, 2004 1:17 AM > To: Susan Hares > Cc: Yakov Rekhter; idr@ietf.org > Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > > On Thu, 15 Apr 2004, Susan Hares wrote: > > Can you clarify something here: > > 1) Your need - informing the remote peer of > > warning limits, stop receive limits, and drop limits > > and SNMP traps, logs etcs > >=20 > > is the basis for the draft. > > We don't really *need* this, because we're monitoring the number of > prefixes advertised by peers. If they go over the top, an alarm > sounds in the NOC. There is no need to inform the peer of the prefix > limits we use, as no prefixes should be dropped based on that, and if > they are, the peer has been badly misbehaving and deserves what it > got. > > Remember, if a peer advertises 100 prefixes, you don't set the prefix=20 > limits to 101 prefixes or even 110 prefixes, but probably something=20 > like 200 or 500 prefixes. > > Our threat model here is, "we want to stop peers from accidentally > advertising the whole Internet or a lot more routes than is normal to > us." > > I.e., a properly administered systems do not need this option. > > But I would not object to having a simple option if that's what others > see useful. I would object to creating a complex option, because that > seems to go too much beyond the cost/benefit curve for an option which > is not needed at all in the first place. > > > 2) Providers we talk to had 2 cases: > > =09 > > 1) creeping VPN prefix limits > > 2) dump of whole routing table > >=20 > > The need to treat the two differently. > > No, I think I disagree with this. Why would they have to be treated=20 > differently? It's the number of prefixes per peer that counts, not=20 > per AFI/SAFI etc. used, or the manner by which they're transmitted. > > You protect your gear at the edge of the network, from either your > peers or your customers (if you import their routes into VPN), so > distinguishing per VPN doesn't seem to be all that useful. > > > 3) Set until changed - that's the rub > >=20 > > The providers wanted to negotiate the capabilties and > > upgrade the capabilities without dropping the connect. > >=20 > > Is that what you mean as well? If so, could you comment > > on what is complex. > > Currently, adding prefix-limits does not drop a session, so it's=20 > required that sessions aren't dropped if the prefix-limits are changed=20 > either. That means that if prefix-limit negotiation is specified, it=20 > must not require a session reset, yes. > =20 > > History:=20 > > We started this out with capabilities on open, and dynamic > > capabilities. Due to some vendor's request to include other > > mechanism (ORF, Soft Notify) to support the dynamic features -=20 > > we added the rest. > >=20 > > Other service providers said, Love the function but could you > > do it by prefix lengths. =20 > >=20 > > In an effort to get something working for all these folks, > > we made these other features optional. =20 > >=20 > > What part don't you like? Cause everything you stated you wanted -- > > is the basic part of the initial draft? Did you dis-like the = > additions > > (ORF, Soft Notify) and or the optional sub-codes?=20 > > > > Do you think we should go back to the initial draft simplistic model? > > It seems to me that if dynamic capabilities is a required-to-implement > mechanism, soft-notify is useless or even problematic (what if you are > doing both?). Similarly, I fail to see any need for ORF (but > admittedly, I haven't looked at it much) or using prefix lengths. =20 > Those who would like to distinguish prefix length in the > prefix-limiter are probably confusing inbound policy with appropriate > prefix-limits. > > So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and=20 > compact to me. > > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 16:47:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18870 for ; Mon, 26 Apr 2004 16:47: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 1BICYH-0005HV-U4 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 16:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QKI5Wv020296 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 16:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBr1-0000ki-Nq for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 15:33:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13840 for ; Mon, 26 Apr 2004 15:33:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBr0-0001PZ-Fp for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:33:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBq4-0001M4-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:32:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBpM-0001I5-00; Mon, 26 Apr 2004 15:31:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBju-0008Ed-St; Mon, 26 Apr 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBaZ-000601-5K for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:16:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12253 for ; Mon, 26 Apr 2004 15:16:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBaX-0000Sx-PN for idr@ietf.org; Mon, 26 Apr 2004 15:16:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBZe-0000OQ-00 for idr@ietf.org; Mon, 26 Apr 2004 15:15:26 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1BIBYr-0000Hj-00 for idr@ietf.org; Mon, 26 Apr 2004 15:14:37 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QJE5Dm011281; Mon, 26 Apr 2004 14:14:06 -0500 (CDT) From: Andrew Lange To: Pedro Roque Marques , Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <2671110.1082981630@[192.168.5.191]> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 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: Mon, 26 Apr 2004 12:13:50 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pedro, Replies are inline. > my recollection is that this draft has been discussed before and that > the majority of the WG requested that encoding and applications of > communities be kept separate. This suggestion was brought up at the SF IETF meeting. There was no action taken to access if this was a majority opinion or not. If we look at the former communities documents (1997 or the ext-comms draft) an initial set of applications is also specified in those documents. The applications specified in this draft parallel the ones specified in 1997 and ext-comms, with a couple of additions (neighbor classes, prepend, announce_with). > reclying the comments: it does appear that the propossed applications > are possible w/ existing protocol support. The author recognises that > some of those applications may or may not be a good idea given that > they seem to impose on an ISP a set of policies which the ISP may or > may not wish to provide... > > reading the document, it seems that the original comments are still > relevant. Could you expand on this a little? As an operator at the time I wrote this, I included a proviso that says that operators MUST be able to turn things off that they do not wish to honor. The application that I think SPs will be cautious with is the ANNOUNCE_WITH option. Some providers will want to allow their customers to do this, but some may not. The basis for this proposal was community policies that providers were already painstakingly using in their networks. The policy actions in the flex comms draft makes those policies easier to express, implement and maintain in SP's networks. Examples would include easy sending of lists of ASNs for NO_EXPORT, neighbor-class functionality, etc. > i also believe that embeding ipv4 and ipv6 addresses into communities is > not a feature... addresses don't make for very good identifiers given > that they may change. Changing addresses can be an operational concern. However, this extends the options that exist for extended communities. You cannot send a IPv6 route-target without the ability to encode an IP address. There are also some tactical situations where a BGP-savvy customer would want to encode an IP address. For example one could wish to prepend to an east-coast peer for its routes to avoid a perceived problem on that peering link. So AS 100 ---- AS 200 ---- AS 100 | AS 5000 AS 5000 would announce to 200 a community where it would ask that a specific prefix or set of prefixes be prepended to AS 100's east-coast peer IP (or neighbor class, if those are configured). AS 200 would prepend, and some of the traffic would move over to the AS100-AS200 west coast link. Andrew _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 16:50:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19509 for ; Mon, 26 Apr 2004 16:50: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 1BICsu-0004Os-ET for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 16:39:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QKdO8B016870 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 16:39:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBxy-0001pA-I0 for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 15:40: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 PAA14411 for ; Mon, 26 Apr 2004 15:40:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBxx-0001tP-6s for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:40:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBwk-0001oI-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 15:39:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBvW-0001ht-00; Mon, 26 Apr 2004 15:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBpi-0000YG-T4; Mon, 26 Apr 2004 15:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBj1-000832-NN for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:25:07 -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 PAA13092 for ; Mon, 26 Apr 2004 15:25:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBj0-0000xN-EH for idr@ietf.org; Mon, 26 Apr 2004 15:25:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBi4-0000va-00 for idr@ietf.org; Mon, 26 Apr 2004 15:24:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BIBhR-0000ru-00 for idr@ietf.org; Mon, 26 Apr 2004 15:23:29 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2004 12:23:00 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-33.cisco.com [10.86.242.33]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3QJMvYu022232; Mon, 26 Apr 2004 15:22:57 -0400 (EDT) From: "zafar ali" To: "'Yakov Rekhter'" , Subject: RE: [Idr] Soft-Notify as an IDR WG document Organization: Cisco Systems Message-ID: <000401c42bc3$e2045b90$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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, 26 Apr 2004 15:22:57 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Yes, this document should be accepted as a WG ID. Thanks Regards... Zafar >-----Original Message----- >From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf >Of Yakov Rekhter >Sent: Monday, April 26, 2004 11:02 AM >To: idr@ietf.org >Subject: [Idr] Soft-Notify as an IDR WG document > > >Folks, > >Please comment on the attached. The deadline for comments is May 10. > >Yakov. > >------- Forwarded Message > >Date: Tue, 20 Apr 2004 12:47:27 -0700 >From: Gargi Nalawade >To: idr@ietf.org >Subject: [Idr] Soft-Notify as IDR WG document > >Hi All, > >I would like to request that BGP Soft-Notify draft, >draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG >document. > >- -Gargi > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > >------- End of Forwarded Message > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 17:25:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24541 for ; Mon, 26 Apr 2004 17:25:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDbM-0005de-Ht for idr-archive@ietf.org; Mon, 26 Apr 2004 17:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDZb-0005Jh-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 17:23:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDXH-0004yv-00; Mon, 26 Apr 2004 17:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDDR-0003Cu-Na; Mon, 26 Apr 2004 17:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID82-0000P2-BD for idr@optimus.ietf.org; Mon, 26 Apr 2004 16:55: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 QAA20457 for ; Mon, 26 Apr 2004 16:54:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BID80-0001bY-9Z for idr@ietf.org; Mon, 26 Apr 2004 16:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICzF-0007kX-00 for idr@ietf.org; Mon, 26 Apr 2004 16:45:59 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BICoL-0005fy-00 for idr@ietf.org; Mon, 26 Apr 2004 16:34:41 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QKY9Fq013047; Mon, 26 Apr 2004 15:34:10 -0500 (CDT) From: Andrew Lange To: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document Message-ID: <7451304.1082986410@[192.168.5.191]> In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 26 Apr 2004 13:33:30 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This draft should be accepted by the WG. It provides a valuable mechanism for today's deployments where we have multiple NLRI in a single session. Andrew --On Monday, April 26, 2004 8:01 AM -0700 Yakov Rekhter wrote: > Folks, > > Please comment on the attached. The deadline for comments is > May 10. > > Yakov. > > ------- Forwarded Message > > Date: Tue, 20 Apr 2004 12:47:27 -0700 > From: Gargi Nalawade > To: idr@ietf.org > Subject: [Idr] Soft-Notify as IDR WG document > > Hi All, > > I would like to request that BGP Soft-Notify draft, > draft-nalawade-bgp-soft-notify-00.txt be accepted as > an IDR WG document. > > - -Gargi > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 17:25:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24603 for ; Mon, 26 Apr 2004 17:25:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDbV-0005fV-Aj for idr-archive@ietf.org; Mon, 26 Apr 2004 17:25:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDZt-0005MF-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 17:23:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDXm-000521-00; Mon, 26 Apr 2004 17:21:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDIi-0004bd-8z; Mon, 26 Apr 2004 17:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDAx-0001YN-99 for idr@optimus.ietf.org; Mon, 26 Apr 2004 16:58:03 -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 QAA20695 for ; Mon, 26 Apr 2004 16:57:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDAv-00024x-8p for idr@ietf.org; Mon, 26 Apr 2004 16:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID1p-0000Uu-00 for idr@ietf.org; Mon, 26 Apr 2004 16:48:39 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1BICrm-0006FK-00 for idr@ietf.org; Mon, 26 Apr 2004 16:38:14 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QKbgTN010072; Mon, 26 Apr 2004 15:37:43 -0500 (CDT) From: Andrew Lange To: Pekka Savola , Pedro Roque Marques cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <7663189.1082986622@[192.168.5.191]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 26 Apr 2004 13:37:02 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Pekka, > Why do we need this in the first place? To "standardize" commonly > used communities? To give the users more tools to mess up their > routing, or to allow the users to make the ISP's policy more complex? Here is some additional text for the introduction which, I hope, will answer your questions. There is a clear demand by BGP-savvy customers to have enhanced control over their route announcements. Today this demand is addressed by custom, complex and difficult to manage community policies. There is no consistency across providers, except for the NO_EXPORT well known community specified in RFC1997. There are more well-known communities for common policies specified in this document to help provide commonality and ease of maintenance. The current route policies required to provide enhanced BGP services are very cumbersome. The larger space provided in flexible communities, and the introduction of neighbor classes significantly ease the implementation and maintenance burdens for service providers. Service providers also often tag their data based on where and from whom they learned it (peer, customer, geographic origin). The flexible community, and the neighbor class application especially, make both assigning inbound communities and matching on outbound peers significantly easier and less error prone. In addition, community values today are simply too small and too rigidly defined to allow for the growth of the Internet. For example, encoding IPv6 address and an action to take on them is simply impossible. > A few nits: > - if EX-COMM doesn't support IPv6 addresses, and that is important > enough, the support MUST be added. EX-COMM is 8 octets. An IPv6 address is 16. As IPv6 deployments progress there will be a demand for encoding IPv6 addresses. > - it might make sense to switch the order of Length and "ASN" fields > for better alignment. Length could also include the ASN field. (Maybe > this would be a more typical TLV encoding?) This would be pretty simple to do. I had structured things the way they are to allow for a larger DATA Field to encode values. We would max out at 251 octets of data with the ASN field second. 251 is probably enough, and we would gain a slightly simpler header and more alignment with existing communities. Okay, I'll reorder those two fields. Andrew > On Wed, 21 Apr 2004, Pedro Roque Marques wrote: >> Yakov Rekhter writes: >> > Folks, It would be greatly appreciated if folks would read the >> > document and comment on it to the IDR mailing list. In other words, >> > we need "yes, looks good" or "should fix this and that", not just >> > silence. >> >> my recollection is that this draft has been discussed before and that >> the majority of the WG requested that encoding and applications of >> communities be kept separate. >> >> reclying the comments: it does appear that the propossed applications >> are possible w/ existing protocol support. The author recognises that >> some of those applications may or may not be a good idea given that >> they seem to impose on an ISP a set of policies which the ISP may or >> may not wish to provide... >> >> reading the document, it seems that the original comments are still >> relevant. >> >> i also believe that embeding ipv4 and ipv6 addresses into communities is >> not a feature... addresses don't make for very good identifiers given >> that they may change. >> >> Pedro. >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr >> > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 17:44:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25962 for ; Mon, 26 Apr 2004 17:44:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDto-00079L-5R for idr-archive@ietf.org; Mon, 26 Apr 2004 17:44:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDsv-00074k-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 17:43:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDsT-00070f-00; Mon, 26 Apr 2004 17:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDa8-0001CP-2z; Mon, 26 Apr 2004 17:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDMo-0005pJ-J2 for idr@optimus.ietf.org; Mon, 26 Apr 2004 17:10:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23230 for ; Mon, 26 Apr 2004 17:10:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDMm-000498-9j for idr@ietf.org; Mon, 26 Apr 2004 17:10:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDLA-0003wn-00 for idr@ietf.org; Mon, 26 Apr 2004 17:08:36 -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 1BIDJO-0003Y9-00 for idr@ietf.org; Mon, 26 Apr 2004 17:06:47 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 13:19:02 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QL67WB014707; Mon, 26 Apr 2004 14:06:11 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL29223; Mon, 26 Apr 2004 14:05:20 -0700 (PDT) Message-ID: <408D79BE.9050203@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques , idr@ietf.org CC: Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> 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: Mon, 26 Apr 2004 14:06:06 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit There are a large number of cases that are frequently hit eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) of a safi, etc where it is unnecessary to penalize other afi/safis that run on the same session. Of course one could limit one afi/safi per session, but unless we change the BGP Spec to force one session per every afi/safi, the reality is going to be that multiple afi/safis would share a single session. If we are talking of changing BGP semantics as it exists today that is a separate issue and independant of this document. This document addresses the problem that exists with today's semantics. It is important that we address today's reality of today's BGP semantics and avoid penalizing the other afi/safis that share the same session in case of errors/actions on any one of them. Hence I propose that this be accepted as a WG document. -Gargi Pedro Roque Marques wrote: > Yakov Rekhter writes: > > >>Folks, Please comment on the attached. The deadline for comments is >>May 10. > > > I dont think this document should be accepted as a work-group > document. The unit of containment in bgp should be the session. We can > possibly have multiple sessions between a pair of systems either via > manual config or with the mecanism that Scudder is proposing. > > Attempting to reset a subset of the nlri is something that won't work > in a considerable number of cases and that adds a very significant > ammount of complexity to BGP. > > I would like to propose that the WG rejects this approach. > > > _______________________________________________ > 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 Mon Apr 26 17:47:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26176 for ; Mon, 26 Apr 2004 17:47: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 1BIDsr-0005re-OV for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 17:43:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLhPKT022538 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 17:43:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDbP-0001Ug-Qg for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24566 for ; Mon, 26 Apr 2004 17:25:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDbN-0005dr-FV for idr-web-archive@ietf.org; Mon, 26 Apr 2004 17:25:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDZd-0005Jz-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 17:23:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDXH-0004yv-00; Mon, 26 Apr 2004 17:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDDR-0003Cu-Na; Mon, 26 Apr 2004 17:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID82-0000P2-BD for idr@optimus.ietf.org; Mon, 26 Apr 2004 16:55: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 QAA20457 for ; Mon, 26 Apr 2004 16:54:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BID80-0001bY-9Z for idr@ietf.org; Mon, 26 Apr 2004 16:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICzF-0007kX-00 for idr@ietf.org; Mon, 26 Apr 2004 16:45:59 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BICoL-0005fy-00 for idr@ietf.org; Mon, 26 Apr 2004 16:34:41 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QKY9Fq013047; Mon, 26 Apr 2004 15:34:10 -0500 (CDT) From: Andrew Lange To: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document Message-ID: <7451304.1082986410@[192.168.5.191]> In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 26 Apr 2004 13:33:30 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This draft should be accepted by the WG. It provides a valuable mechanism for today's deployments where we have multiple NLRI in a single session. Andrew --On Monday, April 26, 2004 8:01 AM -0700 Yakov Rekhter wrote: > Folks, > > Please comment on the attached. The deadline for comments is > May 10. > > Yakov. > > ------- Forwarded Message > > Date: Tue, 20 Apr 2004 12:47:27 -0700 > From: Gargi Nalawade > To: idr@ietf.org > Subject: [Idr] Soft-Notify as IDR WG document > > Hi All, > > I would like to request that BGP Soft-Notify draft, > draft-nalawade-bgp-soft-notify-00.txt be accepted as > an IDR WG document. > > - -Gargi > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > > _______________________________________________ > 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 Mon Apr 26 17:48:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26215 for ; Mon, 26 Apr 2004 17:48: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 1BIDss-0005sK-Gs for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 17:43:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLhQGP022575 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 17:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDbY-0001W4-Sh for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:25:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24623 for ; Mon, 26 Apr 2004 17:25:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDbW-0005fo-7I for idr-web-archive@ietf.org; Mon, 26 Apr 2004 17:25:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDZv-0005MT-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 17:23:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDXm-000521-00; Mon, 26 Apr 2004 17:21:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDIi-0004bd-8z; Mon, 26 Apr 2004 17:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDAx-0001YN-99 for idr@optimus.ietf.org; Mon, 26 Apr 2004 16:58:03 -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 QAA20695 for ; Mon, 26 Apr 2004 16:57:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDAv-00024x-8p for idr@ietf.org; Mon, 26 Apr 2004 16:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID1p-0000Uu-00 for idr@ietf.org; Mon, 26 Apr 2004 16:48:39 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1BICrm-0006FK-00 for idr@ietf.org; Mon, 26 Apr 2004 16:38:14 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QKbgTN010072; Mon, 26 Apr 2004 15:37:43 -0500 (CDT) From: Andrew Lange To: Pekka Savola , Pedro Roque Marques cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <7663189.1082986622@[192.168.5.191]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 26 Apr 2004 13:37:02 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka, > Why do we need this in the first place? To "standardize" commonly > used communities? To give the users more tools to mess up their > routing, or to allow the users to make the ISP's policy more complex? Here is some additional text for the introduction which, I hope, will answer your questions. There is a clear demand by BGP-savvy customers to have enhanced control over their route announcements. Today this demand is addressed by custom, complex and difficult to manage community policies. There is no consistency across providers, except for the NO_EXPORT well known community specified in RFC1997. There are more well-known communities for common policies specified in this document to help provide commonality and ease of maintenance. The current route policies required to provide enhanced BGP services are very cumbersome. The larger space provided in flexible communities, and the introduction of neighbor classes significantly ease the implementation and maintenance burdens for service providers. Service providers also often tag their data based on where and from whom they learned it (peer, customer, geographic origin). The flexible community, and the neighbor class application especially, make both assigning inbound communities and matching on outbound peers significantly easier and less error prone. In addition, community values today are simply too small and too rigidly defined to allow for the growth of the Internet. For example, encoding IPv6 address and an action to take on them is simply impossible. > A few nits: > - if EX-COMM doesn't support IPv6 addresses, and that is important > enough, the support MUST be added. EX-COMM is 8 octets. An IPv6 address is 16. As IPv6 deployments progress there will be a demand for encoding IPv6 addresses. > - it might make sense to switch the order of Length and "ASN" fields > for better alignment. Length could also include the ASN field. (Maybe > this would be a more typical TLV encoding?) This would be pretty simple to do. I had structured things the way they are to allow for a larger DATA Field to encode values. We would max out at 251 octets of data with the ASN field second. 251 is probably enough, and we would gain a slightly simpler header and more alignment with existing communities. Okay, I'll reorder those two fields. Andrew > On Wed, 21 Apr 2004, Pedro Roque Marques wrote: >> Yakov Rekhter writes: >> > Folks, It would be greatly appreciated if folks would read the >> > document and comment on it to the IDR mailing list. In other words, >> > we need "yes, looks good" or "should fix this and that", not just >> > silence. >> >> my recollection is that this draft has been discussed before and that >> the majority of the WG requested that encoding and applications of >> communities be kept separate. >> >> reclying the comments: it does appear that the propossed applications >> are possible w/ existing protocol support. The author recognises that >> some of those applications may or may not be a good idea given that >> they seem to impose on an ISP a set of policies which the ISP may or >> may not wish to provide... >> >> reading the document, it seems that the original comments are still >> relevant. >> >> i also believe that embeding ipv4 and ipv6 addresses into communities is >> not a feature... addresses don't make for very good identifiers given >> that they may change. >> >> Pedro. >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr >> > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 18:05:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27540 for ; Mon, 26 Apr 2004 18:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE3d-0008Cv-So for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 17:54:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLsXET031545 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 17:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDts-0006BL-20 for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:44:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25988 for ; Mon, 26 Apr 2004 17:44:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDtp-00079Y-I1 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 17:44:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDsx-00074z-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 17:43:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDsT-00070f-00; Mon, 26 Apr 2004 17:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDa8-0001CP-2z; Mon, 26 Apr 2004 17:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDMo-0005pJ-J2 for idr@optimus.ietf.org; Mon, 26 Apr 2004 17:10:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23230 for ; Mon, 26 Apr 2004 17:10:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDMm-000498-9j for idr@ietf.org; Mon, 26 Apr 2004 17:10:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDLA-0003wn-00 for idr@ietf.org; Mon, 26 Apr 2004 17:08:36 -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 1BIDJO-0003Y9-00 for idr@ietf.org; Mon, 26 Apr 2004 17:06:47 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 13:19:02 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QL67WB014707; Mon, 26 Apr 2004 14:06:11 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL29223; Mon, 26 Apr 2004 14:05:20 -0700 (PDT) Message-ID: <408D79BE.9050203@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques , idr@ietf.org CC: Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> 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: Mon, 26 Apr 2004 14:06:06 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are a large number of cases that are frequently hit eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) of a safi, etc where it is unnecessary to penalize other afi/safis that run on the same session. Of course one could limit one afi/safi per session, but unless we change the BGP Spec to force one session per every afi/safi, the reality is going to be that multiple afi/safis would share a single session. If we are talking of changing BGP semantics as it exists today that is a separate issue and independant of this document. This document addresses the problem that exists with today's semantics. It is important that we address today's reality of today's BGP semantics and avoid penalizing the other afi/safis that share the same session in case of errors/actions on any one of them. Hence I propose that this be accepted as a WG document. -Gargi Pedro Roque Marques wrote: > Yakov Rekhter writes: > > >>Folks, Please comment on the attached. The deadline for comments is >>May 10. > > > I dont think this document should be accepted as a work-group > document. The unit of containment in bgp should be the session. We can > possibly have multiple sessions between a pair of systems either via > manual config or with the mecanism that Scudder is proposing. > > Attempting to reset a subset of the nlri is something that won't work > in a considerable number of cases and that adds a very significant > ammount of complexity to BGP. > > I would like to propose that the WG rejects this approach. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 18:16:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29035 for ; Mon, 26 Apr 2004 18:16:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEP9-0001qd-Sy for idr-archive@ietf.org; Mon, 26 Apr 2004 18:16:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEO9-0001jp-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 18:15:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIENA-0001et-00; Mon, 26 Apr 2004 18:14:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEEk-0004Y8-9D; Mon, 26 Apr 2004 18: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 1BIE7F-00007Y-6u for idr@optimus.ietf.org; Mon, 26 Apr 2004 17:58:17 -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 RAA26750 for ; Mon, 26 Apr 2004 17:58:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIE7C-0000Q8-E7 for idr@ietf.org; Mon, 26 Apr 2004 17:58:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE6H-0000LR-00 for idr@ietf.org; Mon, 26 Apr 2004 17:57:18 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIE5N-0000FT-00 for idr@ietf.org; Mon, 26 Apr 2004 17:56:21 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QLtP5O020225; Mon, 26 Apr 2004 14:55:25 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QLtPpi020222; Mon, 26 Apr 2004 14:55:25 -0700 (PDT) Message-Id: <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gargi Nalawade Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D79BE.9050203@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 14:55:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > There are a large number of cases that are frequently hit > eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) > of a safi, etc where it is unnecessary to penalize other afi/safis > that run on the same session. How do you recover from those conditions ? notification is just 1/2 of the problem... its isn't enought to address somethis partially. > Of course one could limit one afi/safi > per session, but unless we change the BGP Spec to force one session > per every afi/safi, the reality is going to be that multiple > afi/safis would share a single session. why is that ? with the multisession appoach you can give the operator a pratical way to select the unit of cotainment that it desires. There of course trade-offs in such a choice, such as an increase in the number of objects that need to be monitored from an ops point of view, but the same issues do exist with what you a proposing. > If we are talking of > changing BGP semantics as it exists today that is a separate issue > and independant of this document. This document addresses the > problem that exists with today's semantics. It is important that we > address today's reality of today's BGP semantics and avoid > penalizing the other afi/safis that share the same session in case > of errors/actions on any one of them. You seem to be considering just a subset of the shared fate implied in a bgp session, which btw isn't necessarly a bad thing. The multisession approach seems to me to cover all the scenarios that you describe plus issues that you do not address. > Hence I propose that this be accepted as a WG document. I maintain my opposition. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 18:33:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00449 for ; Mon, 26 Apr 2004 18:33: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 1BIEZx-0004RY-VH for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMRv1B017075 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEPE-00020u-4X for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:16:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29061 for ; Mon, 26 Apr 2004 18:16:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEPB-0001qq-8k for idr-web-archive@ietf.org; Mon, 26 Apr 2004 18:16:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEOA-0001k4-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 18:15:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIENA-0001et-00; Mon, 26 Apr 2004 18:14:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEEk-0004Y8-9D; Mon, 26 Apr 2004 18: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 1BIE7F-00007Y-6u for idr@optimus.ietf.org; Mon, 26 Apr 2004 17:58:17 -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 RAA26750 for ; Mon, 26 Apr 2004 17:58:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIE7C-0000Q8-E7 for idr@ietf.org; Mon, 26 Apr 2004 17:58:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE6H-0000LR-00 for idr@ietf.org; Mon, 26 Apr 2004 17:57:18 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIE5N-0000FT-00 for idr@ietf.org; Mon, 26 Apr 2004 17:56:21 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QLtP5O020225; Mon, 26 Apr 2004 14:55:25 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QLtPpi020222; Mon, 26 Apr 2004 14:55:25 -0700 (PDT) Message-Id: <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gargi Nalawade Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D79BE.9050203@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 14:55:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > There are a large number of cases that are frequently hit > eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) > of a safi, etc where it is unnecessary to penalize other afi/safis > that run on the same session. How do you recover from those conditions ? notification is just 1/2 of the problem... its isn't enought to address somethis partially. > Of course one could limit one afi/safi > per session, but unless we change the BGP Spec to force one session > per every afi/safi, the reality is going to be that multiple > afi/safis would share a single session. why is that ? with the multisession appoach you can give the operator a pratical way to select the unit of cotainment that it desires. There of course trade-offs in such a choice, such as an increase in the number of objects that need to be monitored from an ops point of view, but the same issues do exist with what you a proposing. > If we are talking of > changing BGP semantics as it exists today that is a separate issue > and independant of this document. This document addresses the > problem that exists with today's semantics. It is important that we > address today's reality of today's BGP semantics and avoid > penalizing the other afi/safis that share the same session in case > of errors/actions on any one of them. You seem to be considering just a subset of the shared fate implied in a bgp session, which btw isn't necessarly a bad thing. The multisession approach seems to me to cover all the scenarios that you describe plus issues that you do not address. > Hence I propose that this be accepted as a WG document. I maintain my opposition. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 18:44:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00996 for ; Mon, 26 Apr 2004 18:44:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEqN-0003qE-Um for idr-archive@ietf.org; Mon, 26 Apr 2004 18:44:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEpK-0003fT-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 18:43:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIEoa-0003Wn-04; Mon, 26 Apr 2004 18:43:05 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIEd2-0002kr-Co; Mon, 26 Apr 2004 18:31:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIESM-0003I0-VA; Mon, 26 Apr 2004 18:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEGJ-0005L6-0V for idr@optimus.ietf.org; Mon, 26 Apr 2004 18:07:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27986 for ; Mon, 26 Apr 2004 18:07:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEGG-0001Ff-6O for idr@ietf.org; Mon, 26 Apr 2004 18:07:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEFX-0001Ao-00 for idr@ietf.org; Mon, 26 Apr 2004 18:06:52 -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 1BIEEq-00012d-00 for idr@ietf.org; Mon, 26 Apr 2004 18:06:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 14:17:12 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QM5WW9020515; Mon, 26 Apr 2004 15:05:33 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL35433; Mon, 26 Apr 2004 15:04:45 -0700 (PDT) Message-ID: <408D87AB.7050509@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> 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: Mon, 26 Apr 2004 15:05:31 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pedro Roque Marques wrote: > Gargi Nalawade writes: > > >>There are a large number of cases that are frequently hit >>eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) >>of a safi, etc where it is unnecessary to penalize other afi/safis >>that run on the same session. > > > How do you recover from those conditions ? notification is just 1/2 of > the problem... its isn't enought to address somethis partially. Pls read the draft. It describes how. >>Of course one could limit one afi/safi >>per session, but unless we change the BGP Spec to force one session >>per every afi/safi, the reality is going to be that multiple >>afi/safis would share a single session. > > > why is that ? with the multisession appoach you can give the operator > a pratical way to select the unit of cotainment that it desires. In which case you would still end up containing multiple afi/safis over one session. So we are back to square one. > > There of course trade-offs in such a choice, such as an increase in > the number of objects that need to be monitored from an ops point of > view, but the same issues do exist with what you a proposing. Not really. The soft-notofication does not affcet the number of objects being tracked etc. Everything else stays exactly the same. The afi/safi demarcation is as specified by the BGP Spec today, Soft-Notify does not touch it. If you do, then that would be an implementation limitation or issue. >>If we are talking of >>changing BGP semantics as it exists today that is a separate issue >>and independant of this document. This document addresses the >>problem that exists with today's semantics. It is important that we >>address today's reality of today's BGP semantics and avoid >>penalizing the other afi/safis that share the same session in case >>of errors/actions on any one of them. > > > You seem to be considering just a subset of the shared fate implied in > a bgp session, which btw isn't necessarly a bad thing. > The multisession approach seems to me to cover all the scenarios that Multisession and soft-notify are complementary solutions. The former aims at separating out at the session level and gives a way to automate establishing separate sessions per afi/safi. The latter addresses the problem with today's spec which allows operators to have one session carrying multiple afi/safi's, but penalizes the other safis in case of operations that require reetting of only that afi/safi. > you describe plus issues that you do not address. Like which ones? -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 18:45:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01163 for ; Mon, 26 Apr 2004 18:45:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIErH-0003z0-QV for idr-archive@ietf.org; Mon, 26 Apr 2004 18:45:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEqd-0003ra-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 18:45:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEpV-0003h9-00; Mon, 26 Apr 2004 18:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEik-0006A7-2j; Mon, 26 Apr 2004 18:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEdD-0005QS-PX for idr@optimus.ietf.org; Mon, 26 Apr 2004 18:31: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 SAA00296 for ; Mon, 26 Apr 2004 18:31:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEdA-0002q9-Qy for idr@ietf.org; Mon, 26 Apr 2004 18:31:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEcF-0002md-00 for idr@ietf.org; Mon, 26 Apr 2004 18:30:19 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIEbd-0002ge-00 for idr@ietf.org; Mon, 26 Apr 2004 18:29:41 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QMSx5O020276; Mon, 26 Apr 2004 15:28:59 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QMSxmk020273; Mon, 26 Apr 2004 15:28:59 -0700 (PDT) Message-Id: <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gargi Nalawade Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D87AB.7050509@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 15:28:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > Not really. The soft-notofication does not affcet the number of > objects being tracked etc. Everything else stays exactly the > same. That is an unrealistic claim.. The network operator needs to know that a given set of functionality is working. If you split a set (session) such that parts can fail independently that needs to be monitored. > The afi/safi demarcation is as specified by the BGP Spec > today, Soft-Notify does not touch it. If you do, then that would be > an implementation limitation or issue. Changing the operational model for BGP sessions will add complexity in terms of management. It must be a conscious tradeoff. Again, you can achieve all this in a much simpler way by using multisession, with variable degrees of granularity. > >>If we are talking of >>changing BGP semantics as it exists today > that is a separate issue >>and independant of this document. This > document addresses the >>problem that exists with today's > semantics. It is important that we >>address today's reality of > today's BGP semantics and avoid >>penalizing the other afi/safis > that share the same session in case >>of errors/actions on any one > of them. We are talking about fate-sharing of different afi/safi in a given session. Its is the exact same issue. If you believe you want to manage things with per nlri-type granularity you can do it w. multisession. Besides multisession is 10x easier to implement and deploy since it can use existing state machines. >> you describe plus issues that you do not address. > Like which ones? Like update errors which more likely than not corrupt the tcp stream. Please explain what can be done w. this approach that cannot be done w/ one session per afi/safi or why, given that we are talking about a significant development and deployment (given mgmt impact), this approach is better than using 1 session per afi/safi. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 18:56:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01647 for ; Mon, 26 Apr 2004 18:56: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 1BIEwh-00084D-3p for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 18:51:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMpRp8031001 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 18:51:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEqT-0007Wi-22 for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:45: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 SAA01023 for ; Mon, 26 Apr 2004 18:44:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEqP-0003qX-VF for idr-web-archive@ietf.org; Mon, 26 Apr 2004 18:44:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEpM-0003fh-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 18:43:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIEoa-0003Wn-04; Mon, 26 Apr 2004 18:43:05 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIEd2-0002kr-Co; Mon, 26 Apr 2004 18:31:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIESM-0003I0-VA; Mon, 26 Apr 2004 18:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEGJ-0005L6-0V for idr@optimus.ietf.org; Mon, 26 Apr 2004 18:07:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27986 for ; Mon, 26 Apr 2004 18:07:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEGG-0001Ff-6O for idr@ietf.org; Mon, 26 Apr 2004 18:07:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEFX-0001Ao-00 for idr@ietf.org; Mon, 26 Apr 2004 18:06:52 -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 1BIEEq-00012d-00 for idr@ietf.org; Mon, 26 Apr 2004 18:06:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 14:17:12 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QM5WW9020515; Mon, 26 Apr 2004 15:05:33 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL35433; Mon, 26 Apr 2004 15:04:45 -0700 (PDT) Message-ID: <408D87AB.7050509@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> 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: Mon, 26 Apr 2004 15:05:31 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pedro Roque Marques wrote: > Gargi Nalawade writes: > > >>There are a large number of cases that are frequently hit >>eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) >>of a safi, etc where it is unnecessary to penalize other afi/safis >>that run on the same session. > > > How do you recover from those conditions ? notification is just 1/2 of > the problem... its isn't enought to address somethis partially. Pls read the draft. It describes how. >>Of course one could limit one afi/safi >>per session, but unless we change the BGP Spec to force one session >>per every afi/safi, the reality is going to be that multiple >>afi/safis would share a single session. > > > why is that ? with the multisession appoach you can give the operator > a pratical way to select the unit of cotainment that it desires. In which case you would still end up containing multiple afi/safis over one session. So we are back to square one. > > There of course trade-offs in such a choice, such as an increase in > the number of objects that need to be monitored from an ops point of > view, but the same issues do exist with what you a proposing. Not really. The soft-notofication does not affcet the number of objects being tracked etc. Everything else stays exactly the same. The afi/safi demarcation is as specified by the BGP Spec today, Soft-Notify does not touch it. If you do, then that would be an implementation limitation or issue. >>If we are talking of >>changing BGP semantics as it exists today that is a separate issue >>and independant of this document. This document addresses the >>problem that exists with today's semantics. It is important that we >>address today's reality of today's BGP semantics and avoid >>penalizing the other afi/safis that share the same session in case >>of errors/actions on any one of them. > > > You seem to be considering just a subset of the shared fate implied in > a bgp session, which btw isn't necessarly a bad thing. > The multisession approach seems to me to cover all the scenarios that Multisession and soft-notify are complementary solutions. The former aims at separating out at the session level and gives a way to automate establishing separate sessions per afi/safi. The latter addresses the problem with today's spec which allows operators to have one session carrying multiple afi/safi's, but penalizes the other safis in case of operations that require reetting of only that afi/safi. > you describe plus issues that you do not address. Like which ones? -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 18:56:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01708 for ; Mon, 26 Apr 2004 18:56: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 1BIEwq-00086A-WA for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 18:51:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMpaAI031125 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 18:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIErh-0007a9-LR for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:46:17 -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 SAA01189 for ; Mon, 26 Apr 2004 18:46:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEre-00041N-ME for idr-web-archive@ietf.org; Mon, 26 Apr 2004 18:46:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEqf-0003rw-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 18:45:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEpV-0003h9-00; Mon, 26 Apr 2004 18:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEik-0006A7-2j; Mon, 26 Apr 2004 18:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEdD-0005QS-PX for idr@optimus.ietf.org; Mon, 26 Apr 2004 18:31: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 SAA00296 for ; Mon, 26 Apr 2004 18:31:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEdA-0002q9-Qy for idr@ietf.org; Mon, 26 Apr 2004 18:31:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEcF-0002md-00 for idr@ietf.org; Mon, 26 Apr 2004 18:30:19 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIEbd-0002ge-00 for idr@ietf.org; Mon, 26 Apr 2004 18:29:41 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QMSx5O020276; Mon, 26 Apr 2004 15:28:59 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QMSxmk020273; Mon, 26 Apr 2004 15:28:59 -0700 (PDT) Message-Id: <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gargi Nalawade Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D87AB.7050509@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 15:28:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > Not really. The soft-notofication does not affcet the number of > objects being tracked etc. Everything else stays exactly the > same. That is an unrealistic claim.. The network operator needs to know that a given set of functionality is working. If you split a set (session) such that parts can fail independently that needs to be monitored. > The afi/safi demarcation is as specified by the BGP Spec > today, Soft-Notify does not touch it. If you do, then that would be > an implementation limitation or issue. Changing the operational model for BGP sessions will add complexity in terms of management. It must be a conscious tradeoff. Again, you can achieve all this in a much simpler way by using multisession, with variable degrees of granularity. > >>If we are talking of >>changing BGP semantics as it exists today > that is a separate issue >>and independant of this document. This > document addresses the >>problem that exists with today's > semantics. It is important that we >>address today's reality of > today's BGP semantics and avoid >>penalizing the other afi/safis > that share the same session in case >>of errors/actions on any one > of them. We are talking about fate-sharing of different afi/safi in a given session. Its is the exact same issue. If you believe you want to manage things with per nlri-type granularity you can do it w. multisession. Besides multisession is 10x easier to implement and deploy since it can use existing state machines. >> you describe plus issues that you do not address. > Like which ones? Like update errors which more likely than not corrupt the tcp stream. Please explain what can be done w. this approach that cannot be done w/ one session per afi/safi or why, given that we are talking about a significant development and deployment (given mgmt impact), this approach is better than using 1 session per afi/safi. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 20:07:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05132 for ; Mon, 26 Apr 2004 20:07:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIG8c-00031v-SC for idr-archive@ietf.org; Mon, 26 Apr 2004 20:07:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIG7X-0002tQ-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 20:06:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIG6q-0002lq-00; Mon, 26 Apr 2004 20:06:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIFvI-0003hp-23; Mon, 26 Apr 2004 19:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFrO-0007xA-Cj; Mon, 26 Apr 2004 19:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFql-0007ot-Vh for idr@optimus.ietf.org; Mon, 26 Apr 2004 19:49: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 TAA04227 for ; Mon, 26 Apr 2004 19:49:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIFqk-0001bm-5W for idr@ietf.org; Mon, 26 Apr 2004 19:49:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFpo-0001Xc-00 for idr@ietf.org; Mon, 26 Apr 2004 19:48:25 -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 1BIFoy-0001Oa-00 for idr@ietf.org; Mon, 26 Apr 2004 19:47:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 15:59:49 +0000 Received: from cisco.com ([128.107.177.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QNl0W9015475; Mon, 26 Apr 2004 16:47:00 -0700 (PDT) Message-ID: <408D9F73.1020906@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.82] X-PMX-Version: 4.5.0.92886 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, 26 Apr 2004 16:46:59 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pedro Roque Marques wrote: > Gargi Nalawade writes: > >>Not really. The soft-notofication does not affcet the number of >>objects being tracked etc. Everything else stays exactly the >>same. > > > That is an unrealistic claim.. > The network operator needs to know that a given set of functionality > is working. If you split a set (session) such that parts can fail > independently that needs to be monitored. This already exists today. Look at how Route-refresh for a particular afi/safi works today. This is no different. Unless of course there are implementation-specific issues. > Again, you can achieve all this in a much simpler way by using > multisession, with variable degrees of granularity. Lets not mix this with multisession. That is a different solution with different tradeoffs. Let us talk about Soft-notify here, so we can focus the discussion on the pros & cons of this one. > We are talking about fate-sharing of different afi/safi in a given > session. Its is the exact same issue. Which is as per the BGP-Spec as it exists today. > If you believe you want to manage things with per nlri-type > granularity you can do it w. multisession. Which is a different way of doing it by forcing each afi/safi on a separate session. That too, not always. Note that even with Multisession, multiple afi/safis can share the same session. Soft-notify is aimed at addressing the case when multiple afi/safi's share one session and it is desirable that operations/events in one afi/safi do not affect the operation of the others on the same session as itself. > Besides multisession is 10x easier to implement and deploy since it > can use existing state machines. Depends on the implementation :) >>>you describe plus issues that you do not address. >> > >>Like which ones? > > > Like update errors which more likely than not corrupt the tcp > stream. For those cases, the draft proposes using Notifications instead of Soft-Notifications. > > Please explain what can be done w. this approach that cannot be done > w/ one session per afi/safi or why, given that we are talking about a > significant development and deployment (given mgmt impact), this > approach is better than using 1 session per afi/safi. The point is not to force all afi/safi's on a single session. The solution-space addressed by this document is the existing deployments and the existing BGP-Spec where operators either have or may choose to have multiple afi/safi's on a single session. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 20:19:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05548 for ; Mon, 26 Apr 2004 20:19:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGGN-0002Ug-0N for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 20:15:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R0FoPU009578 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 20:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIG8g-0001mA-1I for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 20:07:54 -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 UAA05157 for ; Mon, 26 Apr 2004 20:07:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIG8e-000328-1b for idr-web-archive@ietf.org; Mon, 26 Apr 2004 20:07:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIG7Z-0002te-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 20:06:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIG6q-0002lq-00; Mon, 26 Apr 2004 20:06:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIFvI-0003hp-23; Mon, 26 Apr 2004 19:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFrO-0007xA-Cj; Mon, 26 Apr 2004 19:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFql-0007ot-Vh for idr@optimus.ietf.org; Mon, 26 Apr 2004 19:49: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 TAA04227 for ; Mon, 26 Apr 2004 19:49:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIFqk-0001bm-5W for idr@ietf.org; Mon, 26 Apr 2004 19:49:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFpo-0001Xc-00 for idr@ietf.org; Mon, 26 Apr 2004 19:48:25 -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 1BIFoy-0001Oa-00 for idr@ietf.org; Mon, 26 Apr 2004 19:47:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 15:59:49 +0000 Received: from cisco.com ([128.107.177.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QNl0W9015475; Mon, 26 Apr 2004 16:47:00 -0700 (PDT) Message-ID: <408D9F73.1020906@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.82] X-PMX-Version: 4.5.0.92886 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, 26 Apr 2004 16:46:59 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pedro Roque Marques wrote: > Gargi Nalawade writes: > >>Not really. The soft-notofication does not affcet the number of >>objects being tracked etc. Everything else stays exactly the >>same. > > > That is an unrealistic claim.. > The network operator needs to know that a given set of functionality > is working. If you split a set (session) such that parts can fail > independently that needs to be monitored. This already exists today. Look at how Route-refresh for a particular afi/safi works today. This is no different. Unless of course there are implementation-specific issues. > Again, you can achieve all this in a much simpler way by using > multisession, with variable degrees of granularity. Lets not mix this with multisession. That is a different solution with different tradeoffs. Let us talk about Soft-notify here, so we can focus the discussion on the pros & cons of this one. > We are talking about fate-sharing of different afi/safi in a given > session. Its is the exact same issue. Which is as per the BGP-Spec as it exists today. > If you believe you want to manage things with per nlri-type > granularity you can do it w. multisession. Which is a different way of doing it by forcing each afi/safi on a separate session. That too, not always. Note that even with Multisession, multiple afi/safis can share the same session. Soft-notify is aimed at addressing the case when multiple afi/safi's share one session and it is desirable that operations/events in one afi/safi do not affect the operation of the others on the same session as itself. > Besides multisession is 10x easier to implement and deploy since it > can use existing state machines. Depends on the implementation :) >>>you describe plus issues that you do not address. >> > >>Like which ones? > > > Like update errors which more likely than not corrupt the tcp > stream. For those cases, the draft proposes using Notifications instead of Soft-Notifications. > > Please explain what can be done w. this approach that cannot be done > w/ one session per afi/safi or why, given that we are talking about a > significant development and deployment (given mgmt impact), this > approach is better than using 1 session per afi/safi. The point is not to force all afi/safi's on a single session. The solution-space addressed by this document is the existing deployments and the existing BGP-Spec where operators either have or may choose to have multiple afi/safi's on a single session. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 20:49:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06879 for ; Mon, 26 Apr 2004 20:49:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIGmw-0006oW-7i for idr-archive@ietf.org; Mon, 26 Apr 2004 20:49:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGm2-0006il-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 20:48:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIGlW-0006d9-00; Mon, 26 Apr 2004 20:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGhf-0006Pn-Ab; Mon, 26 Apr 2004 20:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGeB-00060d-QA for idr@optimus.ietf.org; Mon, 26 Apr 2004 20:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06429 for ; Mon, 26 Apr 2004 20:40:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIGe9-0005uc-H7 for idr@ietf.org; Mon, 26 Apr 2004 20:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGdI-0005nD-00 for idr@ietf.org; Mon, 26 Apr 2004 20:39:32 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIGcH-0005Zr-00 for idr@ietf.org; Mon, 26 Apr 2004 20:38:29 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3R0bq5O020467; Mon, 26 Apr 2004 17:37:52 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3R0bqKi020464; Mon, 26 Apr 2004 17:37:52 -0700 (PDT) Message-Id: <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D9F73.1020906@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 17:37:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > Pedro Roque Marques wrote: >> Gargi Nalawade writes: >> > >>Not really. The soft-notofication does not affcet the number of > >>objects being tracked etc. Everything else stays exactly the > >>same. >> >> >> That is an unrealistic claim.. The network operator needs to know >> that a given set of functionality is working. If you split a set >> (session) such that parts can fail independently that needs to be >> monitored. > This already exists today. Look at how Route-refresh for a > particular afi/safi works today. This is no different. Unless of > course there are implementation-specific issues. No, sub-states within a bgp session do not exist. A session is either working w/ all the functionality that has been configured on it, or its is not. > Lets not mix this with multisession. That is a different solution > with different tradeoffs. Let us talk about Soft-notify here, so we > can focus the discussion on the pros & cons of this one. Lets not. What is relavant is to address a particular problem and to consider what option to chose we must contrast several approaches. >> If you believe you want to manage things with per nlri-type >> granularity you can do it w. multisession. > Which is a different way of doing it by forcing each afi/safi on a > separate session. so you do agree that multisession is a different way to solve the problem. > That too, not always. Note that even with > Multisession, multiple afi/safis can share the same session. That doesnt mean that multisession can't be used w/ 1 session per nlri... in fact it allows you to control exactly what granularity is desired. > Soft-notify is aimed at addressing the case when multiple afi/safi's > share one session and why would you do that *and* want per nlri mgmt of the session ??? >> Besides multisession is 10x easier to implement and deploy since it >> can use existing state machines. > Depends on the implementation :) The deployment part of the equation doesn't... Ops people understand the bgp state machine... its easy to add the concept of multisession on top. Its is a much more significant chalenge to add this per nlri up/down negotiation. >> Like update errors which more likely than not corrupt the tcp >> stream. > For those cases, the draft proposes using Notifications instead of > Soft-Notifications. Which doesnt provide fault containment. I'd rather have a single way of fault containment that works across all reasons for session failure... >> Please explain what can be done w. this approach that cannot be >> done w/ one session per afi/safi or why, given that we are talking >> about a significant development and deployment (given mgmt impact), >> this approach is better than using 1 session per afi/safi. > The point is not to force all afi/safi's on a single session. But you haven't explained why that should be a goal... > The > solution-space addressed by this document is the existing > deployments and the existing BGP-Spec where operators either have or > may choose to have multiple afi/safi's on a single session. Why don't we consider the reasons why one would like to have different afi/safi pairs in the same session and then ask ourselfs what having indepent notifications/up events will buy you. I can come up w/ 2 simple scenarios: a) you want fate sharing... i.e. intentionally tie afis so that when one fails the other does fail also. (both are required to provide a service for instance). b) you don't want to deal w/ the extra complexity of monitoring multiple substates and prefer to deal w/ a binary "works" / "broken". In both these examples which i consider rather realistic adding notifications/negotiation does not provide value. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 20:54:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07041 for ; Mon, 26 Apr 2004 20:54:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGqt-0007d2-H5 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 20:53:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R0rZYi029318 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 20:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGmz-00071d-Vc for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 20:49: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 UAA06905 for ; Mon, 26 Apr 2004 20:49:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIGmx-0006oi-I1 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 20:49:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGm4-0006iz-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 20:48:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIGlW-0006d9-00; Mon, 26 Apr 2004 20:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGhf-0006Pn-Ab; Mon, 26 Apr 2004 20:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGeB-00060d-QA for idr@optimus.ietf.org; Mon, 26 Apr 2004 20:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06429 for ; Mon, 26 Apr 2004 20:40:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIGe9-0005uc-H7 for idr@ietf.org; Mon, 26 Apr 2004 20:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGdI-0005nD-00 for idr@ietf.org; Mon, 26 Apr 2004 20:39:32 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIGcH-0005Zr-00 for idr@ietf.org; Mon, 26 Apr 2004 20:38:29 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3R0bq5O020467; Mon, 26 Apr 2004 17:37:52 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3R0bqKi020464; Mon, 26 Apr 2004 17:37:52 -0700 (PDT) Message-Id: <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D9F73.1020906@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 26 Apr 2004 17:37:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > Pedro Roque Marques wrote: >> Gargi Nalawade writes: >> > >>Not really. The soft-notofication does not affcet the number of > >>objects being tracked etc. Everything else stays exactly the > >>same. >> >> >> That is an unrealistic claim.. The network operator needs to know >> that a given set of functionality is working. If you split a set >> (session) such that parts can fail independently that needs to be >> monitored. > This already exists today. Look at how Route-refresh for a > particular afi/safi works today. This is no different. Unless of > course there are implementation-specific issues. No, sub-states within a bgp session do not exist. A session is either working w/ all the functionality that has been configured on it, or its is not. > Lets not mix this with multisession. That is a different solution > with different tradeoffs. Let us talk about Soft-notify here, so we > can focus the discussion on the pros & cons of this one. Lets not. What is relavant is to address a particular problem and to consider what option to chose we must contrast several approaches. >> If you believe you want to manage things with per nlri-type >> granularity you can do it w. multisession. > Which is a different way of doing it by forcing each afi/safi on a > separate session. so you do agree that multisession is a different way to solve the problem. > That too, not always. Note that even with > Multisession, multiple afi/safis can share the same session. That doesnt mean that multisession can't be used w/ 1 session per nlri... in fact it allows you to control exactly what granularity is desired. > Soft-notify is aimed at addressing the case when multiple afi/safi's > share one session and why would you do that *and* want per nlri mgmt of the session ??? >> Besides multisession is 10x easier to implement and deploy since it >> can use existing state machines. > Depends on the implementation :) The deployment part of the equation doesn't... Ops people understand the bgp state machine... its easy to add the concept of multisession on top. Its is a much more significant chalenge to add this per nlri up/down negotiation. >> Like update errors which more likely than not corrupt the tcp >> stream. > For those cases, the draft proposes using Notifications instead of > Soft-Notifications. Which doesnt provide fault containment. I'd rather have a single way of fault containment that works across all reasons for session failure... >> Please explain what can be done w. this approach that cannot be >> done w/ one session per afi/safi or why, given that we are talking >> about a significant development and deployment (given mgmt impact), >> this approach is better than using 1 session per afi/safi. > The point is not to force all afi/safi's on a single session. But you haven't explained why that should be a goal... > The > solution-space addressed by this document is the existing > deployments and the existing BGP-Spec where operators either have or > may choose to have multiple afi/safi's on a single session. Why don't we consider the reasons why one would like to have different afi/safi pairs in the same session and then ask ourselfs what having indepent notifications/up events will buy you. I can come up w/ 2 simple scenarios: a) you want fate sharing... i.e. intentionally tie afis so that when one fails the other does fail also. (both are required to provide a service for instance). b) you don't want to deal w/ the extra complexity of monitoring multiple substates and prefer to deal w/ a binary "works" / "broken". In both these examples which i consider rather realistic adding notifications/negotiation does not provide value. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Apr 26 21:27:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08510 for ; Mon, 26 Apr 2004 21:27:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHNn-0002rT-4x for idr-archive@ietf.org; Mon, 26 Apr 2004 21:27:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHMq-0002kv-00 for idr-archive@ietf.org; Mon, 26 Apr 2004 21:26:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIHM8-0002ex-00; Mon, 26 Apr 2004 21:25:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHJP-0002i0-6O; Mon, 26 Apr 2004 21:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHF9-0001tJ-4b for idr@optimus.ietf.org; Mon, 26 Apr 2004 21:18:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08098 for ; Mon, 26 Apr 2004 21:18:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHF6-0001s4-Gs for idr@ietf.org; Mon, 26 Apr 2004 21:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHEL-0001mO-00 for idr@ietf.org; Mon, 26 Apr 2004 21:17:50 -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 1BIHDi-0001eA-00 for idr@ietf.org; Mon, 26 Apr 2004 21:17:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 17:29:28 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3R1GXSu007661; Mon, 26 Apr 2004 18:16:38 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL51033; Mon, 26 Apr 2004 18:15:46 -0700 (PDT) Message-ID: <408DB470.4090505@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> 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: Mon, 26 Apr 2004 18:16:32 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > No, sub-states within a bgp session do not exist. A session is either > working w/ all the functionality that has been configured on it, or > its is not. This is an implementation-specific design choice. >>That too, not always. Note that even with >>Multisession, multiple afi/safis can share the same session. > > That doesnt mean that multisession can't be used w/ 1 session per > nlri... in fact it allows you to control exactly what granularity is > desired. Exactly. It also does not mean that it always mandates running one afi/safi per session, which brings us back to today's BGP spec. So lets just talk about that. > > >>Soft-notify is aimed at addressing the case when multiple afi/safi's >>share one session > > and why would you do that *and* want per nlri mgmt of the session ??? Soft-notify does not need per-nlri "session"management. Whatever management is needed - the state-machine and infra for that already exists post- MP_REACH. Unless some implementation has limittaions, in which case it is for that implementation to fix. > The deployment part of the equation doesn't... > Ops people understand the bgp state machine... its easy to add the > concept of multisession on top. Its is a much more significant > chalenge to add this per nlri up/down negotiation. I dont see any per nlri negotiation challenges. The mechanism exists today and it works. >>For those cases, the draft proposes using Notifications instead of >>Soft-Notifications. > > > Which doesnt provide fault containment. I'd rather have a single way > of fault containment that works across all reasons for session > failure... For session-failures yes. But theer are errors such as CEASE which should not require a session-failure as they are independent of that. > > Why don't we consider the reasons why one would like to have different > afi/safi pairs in the same session and then ask ourselfs what having > indepent notifications/up events will buy you. Reduced #sessions, avoid session reestab latency (we are after all limited by the speed of light :)), reduced overhead in terms of resources that need to be allocated per-session and so on.. > > I can come up w/ 2 simple scenarios: > a) you want fate sharing... i.e. intentionally tie afis so that when > one fails the other does fail also. (both are required to provide a > service for instance). > b) you don't want to deal w/ the extra complexity of monitoring > multiple substates and prefer to deal w/ a binary "works" / "broken". > > In both these examples which i consider rather realistic adding > notifications/negotiation does not provide value. Give me one Provider who says that because IPv4 Unicast in their network is needed for providing some IPv4 Multicast service, IPv4 unicast should fail whenever IPv4 Multicast has an error or a CEASE notification. I dont think these are realistic scenarios. However, thank you for your opinion. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Apr 26 21:35:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08933 for ; Mon, 26 Apr 2004 21:35: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 1BIHSx-0003nQ-EO for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 21:32:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R1WtNv014588 for idr-archive@odin.ietf.org; Mon, 26 Apr 2004 21:32:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHNr-0003K8-6Z for idr-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 21:27:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08536 for ; Mon, 26 Apr 2004 21:27:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHNo-0002rd-Fw for idr-web-archive@ietf.org; Mon, 26 Apr 2004 21:27:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHMs-0002l9-00 for idr-web-archive@ietf.org; Mon, 26 Apr 2004 21:26:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIHM8-0002ex-00; Mon, 26 Apr 2004 21:25:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHJP-0002i0-6O; Mon, 26 Apr 2004 21:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHF9-0001tJ-4b for idr@optimus.ietf.org; Mon, 26 Apr 2004 21:18:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08098 for ; Mon, 26 Apr 2004 21:18:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHF6-0001s4-Gs for idr@ietf.org; Mon, 26 Apr 2004 21:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHEL-0001mO-00 for idr@ietf.org; Mon, 26 Apr 2004 21:17:50 -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 1BIHDi-0001eA-00 for idr@ietf.org; Mon, 26 Apr 2004 21:17:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 17:29:28 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3R1GXSu007661; Mon, 26 Apr 2004 18:16:38 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL51033; Mon, 26 Apr 2004 18:15:46 -0700 (PDT) Message-ID: <408DB470.4090505@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> 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: Mon, 26 Apr 2004 18:16:32 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > No, sub-states within a bgp session do not exist. A session is either > working w/ all the functionality that has been configured on it, or > its is not. This is an implementation-specific design choice. >>That too, not always. Note that even with >>Multisession, multiple afi/safis can share the same session. > > That doesnt mean that multisession can't be used w/ 1 session per > nlri... in fact it allows you to control exactly what granularity is > desired. Exactly. It also does not mean that it always mandates running one afi/safi per session, which brings us back to today's BGP spec. So lets just talk about that. > > >>Soft-notify is aimed at addressing the case when multiple afi/safi's >>share one session > > and why would you do that *and* want per nlri mgmt of the session ??? Soft-notify does not need per-nlri "session"management. Whatever management is needed - the state-machine and infra for that already exists post- MP_REACH. Unless some implementation has limittaions, in which case it is for that implementation to fix. > The deployment part of the equation doesn't... > Ops people understand the bgp state machine... its easy to add the > concept of multisession on top. Its is a much more significant > chalenge to add this per nlri up/down negotiation. I dont see any per nlri negotiation challenges. The mechanism exists today and it works. >>For those cases, the draft proposes using Notifications instead of >>Soft-Notifications. > > > Which doesnt provide fault containment. I'd rather have a single way > of fault containment that works across all reasons for session > failure... For session-failures yes. But theer are errors such as CEASE which should not require a session-failure as they are independent of that. > > Why don't we consider the reasons why one would like to have different > afi/safi pairs in the same session and then ask ourselfs what having > indepent notifications/up events will buy you. Reduced #sessions, avoid session reestab latency (we are after all limited by the speed of light :)), reduced overhead in terms of resources that need to be allocated per-session and so on.. > > I can come up w/ 2 simple scenarios: > a) you want fate sharing... i.e. intentionally tie afis so that when > one fails the other does fail also. (both are required to provide a > service for instance). > b) you don't want to deal w/ the extra complexity of monitoring > multiple substates and prefer to deal w/ a binary "works" / "broken". > > In both these examples which i consider rather realistic adding > notifications/negotiation does not provide value. Give me one Provider who says that because IPv4 Unicast in their network is needed for providing some IPv4 Multicast service, IPv4 unicast should fail whenever IPv4 Multicast has an error or a CEASE notification. I dont think these are realistic scenarios. However, thank you for your opinion. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 27 02:55:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08947 for ; Tue, 27 Apr 2004 02:55:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMUf-00027x-97 for idr-archive@ietf.org; Tue, 27 Apr 2004 02:55:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMTe-0001w1-00 for idr-archive@ietf.org; Tue, 27 Apr 2004 02:53:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMT5-0001kQ-00; Tue, 27 Apr 2004 02:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIML1-0001zM-L4; Tue, 27 Apr 2004 02:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMFp-0000ty-Du for idr@optimus.ietf.org; Tue, 27 Apr 2004 02:39:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07818 for ; Tue, 27 Apr 2004 02:39:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMFl-0006zg-L1 for idr@ietf.org; Tue, 27 Apr 2004 02:39:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMEq-0006pq-00 for idr@ietf.org; Tue, 27 Apr 2004 02:38:41 -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 1BIME0-0006W0-00 for idr@ietf.org; Tue, 27 Apr 2004 02:37:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 22:50:10 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R6bGW9016203; Mon, 26 Apr 2004 23:37:17 -0700 (PDT) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL64644; Mon, 26 Apr 2004 23:36:28 -0700 (PDT) Message-ID: <408DFF99.7060601@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John G. Scudder" CC: idr@ietf.org Subject: Re: [Idr] Multisession as WG doc References: In-Reply-To: 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: Mon, 26 Apr 2004 23:37:13 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I support multisession draft to become an IDR WG doc. R. > John G. Scudder wrote: > > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working > group document. > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 27 03:06:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09631 for ; Tue, 27 Apr 2004 03:06:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMYB-0003gD-8u for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 02:58:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R6wd6C014145 for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 02:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMUk-0003H8-Kn for idr-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 02:55: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 CAA08987 for ; Tue, 27 Apr 2004 02:55:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMUg-000287-Is for idr-web-archive@ietf.org; Tue, 27 Apr 2004 02:55:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMTg-0001wG-00 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 02:54:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMT5-0001kQ-00; Tue, 27 Apr 2004 02:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIML1-0001zM-L4; Tue, 27 Apr 2004 02:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMFp-0000ty-Du for idr@optimus.ietf.org; Tue, 27 Apr 2004 02:39:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07818 for ; Tue, 27 Apr 2004 02:39:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMFl-0006zg-L1 for idr@ietf.org; Tue, 27 Apr 2004 02:39:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMEq-0006pq-00 for idr@ietf.org; Tue, 27 Apr 2004 02:38:41 -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 1BIME0-0006W0-00 for idr@ietf.org; Tue, 27 Apr 2004 02:37:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 22:50:10 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R6bGW9016203; Mon, 26 Apr 2004 23:37:17 -0700 (PDT) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL64644; Mon, 26 Apr 2004 23:36:28 -0700 (PDT) Message-ID: <408DFF99.7060601@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John G. Scudder" CC: idr@ietf.org Subject: Re: [Idr] Multisession as WG doc References: In-Reply-To: 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: Mon, 26 Apr 2004 23:37:13 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I support multisession draft to become an IDR WG doc. R. > John G. Scudder wrote: > > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working > group document. > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 27 03:41:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11485 for ; Tue, 27 Apr 2004 03:41:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINDM-0002a0-BD for idr-archive@ietf.org; Tue, 27 Apr 2004 03:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINC8-0002Nd-00 for idr-archive@ietf.org; Tue, 27 Apr 2004 03:39:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BINBc-0002C0-00; Tue, 27 Apr 2004 03:39:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN3a-0007q1-Nz; Tue, 27 Apr 2004 03:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN0G-0007Ch-Of for idr@optimus.ietf.org; Tue, 27 Apr 2004 03:27: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 DAA10697 for ; Tue, 27 Apr 2004 03:27:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIN0E-0000ES-IG for idr@ietf.org; Tue, 27 Apr 2004 03:27:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMzK-00002V-00 for idr@ietf.org; Tue, 27 Apr 2004 03:26:43 -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 1BIMya-0007VO-00 for idr@ietf.org; Tue, 27 Apr 2004 03:25:56 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 23:38:18 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R7PPW9021215; Tue, 27 Apr 2004 00:25:25 -0700 (PDT) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL66492; Tue, 27 Apr 2004 00:24:35 -0700 (PDT) Message-ID: <408E0AE0.4090701@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org CC: Pedro Roque Marques , gargi@cisco.com, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> In-Reply-To: <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> 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, 27 Apr 2004 00:25:20 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, > The deployment part of the equation doesn't... > Ops people understand the bgp state machine... its easy to add the > concept of multisession on top. Its is a much more significant > chalenge to add this per nlri up/down negotiation. Yes I agree that soft notify adds a new layer of troubleshooting & deployment complexity. While today most of the monitoring tools or SNMP work on a per session granularity it would require to be immediately updated to go deeper to the AFI/SAFI per session levels. Otherwise operators may have a really hard time to monitor what is going on. And unless they know that one AFI/SAFI is down under a working BGP session their NOC can't log in and fix the problem hence end customers may be impacted. Maybe it goes without saying that modifications to a number of show commands would be also required. On the other hand what is not clear to me is why do we equate Soft-Notify to address just the session reset piece. For whatever it is worth my observations of various BGP deployments today lead me to believe that BGP code in most implementations does not trigger session Notifications in the first place that often ;). So I am not sure if we are solving a real problem here. And the problem at hand should be solved with the simplest solution so multisession seems to fit the bill. Moreover multisession seems to be an automation to today's manual session separation which some operators are already using. That said I think one could observe that Soft-Notify does not just address the reset problem. Well maybe the name of the draft is wrong :) The functionality I support in it is to inform the peer about some BGP actions or events without resetting the session. As original INFORM draft was proposing and very similar to what Enke's cease msg defines for the Notification itself. Just an real live example ... BGP draft says: A BGP speaker MAY support the ability to impose an (locally config- ured) upper bound on the number of address prefixes the speaker is willing to accept from a neighbor. When the upper bound is reached, the speaker (under control of local configuration) either (a) dis- cards new address prefixes from the neighbor (while maintaining BGP connection with the neighbor), or (b) terminates the BGP connection with the neighbor. If the BGP speaker decides to terminate its BGP connection with a neighbor because the number of address prefixes received from the neighbor exceeds the locally configured upper bound, then the speaker MUST send to the neighbor a NOTIFICATION mes- sage with the Error Code Cease. The speaker MAY also log this locally. So in the case operator choose to select option (a) above his EBGP peer has no way of knowing about action of his peer. So maybe a good approach would be to reword the draft to primarily deliver the BGP event messaging between peers not causing the session resets while still allowing an optional vendor specific pool of msg types. Therefor market and operators could decide which messages/actions are useful and which not ... In that light I would support to accept the reworded draft as an IDR WG doc. R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 27 03:48:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11818 for ; Tue, 27 Apr 2004 03:48: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 1BINFP-0001Ev-Nh for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 03:43:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R7hJtC004760 for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 03:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINDQ-000112-3V for idr-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 03:41: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 DAA11511 for ; Tue, 27 Apr 2004 03:41:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINDN-0002aB-MZ for idr-web-archive@ietf.org; Tue, 27 Apr 2004 03:41:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINCA-0002Nr-00 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 03:39:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BINBc-0002C0-00; Tue, 27 Apr 2004 03:39:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN3a-0007q1-Nz; Tue, 27 Apr 2004 03:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN0G-0007Ch-Of for idr@optimus.ietf.org; Tue, 27 Apr 2004 03:27: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 DAA10697 for ; Tue, 27 Apr 2004 03:27:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIN0E-0000ES-IG for idr@ietf.org; Tue, 27 Apr 2004 03:27:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMzK-00002V-00 for idr@ietf.org; Tue, 27 Apr 2004 03:26:43 -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 1BIMya-0007VO-00 for idr@ietf.org; Tue, 27 Apr 2004 03:25:56 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 23:38:18 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R7PPW9021215; Tue, 27 Apr 2004 00:25:25 -0700 (PDT) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL66492; Tue, 27 Apr 2004 00:24:35 -0700 (PDT) Message-ID: <408E0AE0.4090701@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org CC: Pedro Roque Marques , gargi@cisco.com, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> In-Reply-To: <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> 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, 27 Apr 2004 00:25:20 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, > The deployment part of the equation doesn't... > Ops people understand the bgp state machine... its easy to add the > concept of multisession on top. Its is a much more significant > chalenge to add this per nlri up/down negotiation. Yes I agree that soft notify adds a new layer of troubleshooting & deployment complexity. While today most of the monitoring tools or SNMP work on a per session granularity it would require to be immediately updated to go deeper to the AFI/SAFI per session levels. Otherwise operators may have a really hard time to monitor what is going on. And unless they know that one AFI/SAFI is down under a working BGP session their NOC can't log in and fix the problem hence end customers may be impacted. Maybe it goes without saying that modifications to a number of show commands would be also required. On the other hand what is not clear to me is why do we equate Soft-Notify to address just the session reset piece. For whatever it is worth my observations of various BGP deployments today lead me to believe that BGP code in most implementations does not trigger session Notifications in the first place that often ;). So I am not sure if we are solving a real problem here. And the problem at hand should be solved with the simplest solution so multisession seems to fit the bill. Moreover multisession seems to be an automation to today's manual session separation which some operators are already using. That said I think one could observe that Soft-Notify does not just address the reset problem. Well maybe the name of the draft is wrong :) The functionality I support in it is to inform the peer about some BGP actions or events without resetting the session. As original INFORM draft was proposing and very similar to what Enke's cease msg defines for the Notification itself. Just an real live example ... BGP draft says: A BGP speaker MAY support the ability to impose an (locally config- ured) upper bound on the number of address prefixes the speaker is willing to accept from a neighbor. When the upper bound is reached, the speaker (under control of local configuration) either (a) dis- cards new address prefixes from the neighbor (while maintaining BGP connection with the neighbor), or (b) terminates the BGP connection with the neighbor. If the BGP speaker decides to terminate its BGP connection with a neighbor because the number of address prefixes received from the neighbor exceeds the locally configured upper bound, then the speaker MUST send to the neighbor a NOTIFICATION mes- sage with the Error Code Cease. The speaker MAY also log this locally. So in the case operator choose to select option (a) above his EBGP peer has no way of knowing about action of his peer. So maybe a good approach would be to reword the draft to primarily deliver the BGP event messaging between peers not causing the session resets while still allowing an optional vendor specific pool of msg types. Therefor market and operators could decide which messages/actions are useful and which not ... In that light I would support to accept the reworded draft as an IDR WG doc. R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 27 06:41:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21113 for ; Tue, 27 Apr 2004 06:41:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQ2A-0007e7-6I for idr-archive@ietf.org; Tue, 27 Apr 2004 06:41:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQ1E-0007RB-00 for idr-archive@ietf.org; Tue, 27 Apr 2004 06:40:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIQ0T-0007FT-00; Tue, 27 Apr 2004 06:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPor-00007t-IP; Tue, 27 Apr 2004 06:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPh3-0007Io-4M for idr@optimus.ietf.org; Tue, 27 Apr 2004 06:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19890 for ; Tue, 27 Apr 2004 06:19:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPgz-0002xy-9A for idr@ietf.org; Tue, 27 Apr 2004 06:19:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPg2-0002lI-00 for idr@ietf.org; Tue, 27 Apr 2004 06:18:58 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIPf9-0002Lj-00 for idr@ietf.org; Tue, 27 Apr 2004 06:18:03 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3RAGYF13177; Tue, 27 Apr 2004 13:16:34 +0300 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , , Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408DB470.4090505@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 13:16:34 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 26 Apr 2004, Gargi Nalawade wrote: > > I can come up w/ 2 simple scenarios: > > a) you want fate sharing... i.e. intentionally tie afis so that when > > one fails the other does fail also. (both are required to provide a > > service for instance). > > b) you don't want to deal w/ the extra complexity of monitoring > > multiple substates and prefer to deal w/ a binary "works" / "broken". > > > > In both these examples which i consider rather realistic adding > > notifications/negotiation does not provide value. > > Give me one Provider who says that because IPv4 Unicast in their network > is needed for providing some IPv4 Multicast service, IPv4 unicast should > fail whenever IPv4 Multicast has an error or a CEASE notification. And when would such an error occur? If you have shared unicast/multicast infrastructure, pretty much never, unless both would be equally impacted. And when the topologies aren't congruent, then you will notice it in any case. I share Pedro's concerns about the applicability. If operators see it important to protect AFI/SAFIs from each other, something like "multisession" seems like an obvious choice. If there is an obvious choice, it will be deployed as well. It seems like we're talking about a solution which would become interesting either in the scenario where 1) operator is not (sufficiently interested) for doing something like multi-session BGP (but could be interested in something like this), or 2) operator doesn't want to wait for multi-session, and wants something sooner. Both of these scenarios seem very questionable to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 27 06:48:31 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21587 for ; Tue, 27 Apr 2004 06:48: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 1BIQ69-0003LG-KV for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 06:45:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RAjvJS012842 for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 06:45:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQ2F-0002HB-HV for idr-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:41: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 GAA21139 for ; Tue, 27 Apr 2004 06:41:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQ2B-0007eH-H6 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 06:41:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQ1F-0007RP-00 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 06:40:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIQ0T-0007FT-00; Tue, 27 Apr 2004 06:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPor-00007t-IP; Tue, 27 Apr 2004 06:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPh3-0007Io-4M for idr@optimus.ietf.org; Tue, 27 Apr 2004 06:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19890 for ; Tue, 27 Apr 2004 06:19:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPgz-0002xy-9A for idr@ietf.org; Tue, 27 Apr 2004 06:19:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPg2-0002lI-00 for idr@ietf.org; Tue, 27 Apr 2004 06:18:58 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIPf9-0002Lj-00 for idr@ietf.org; Tue, 27 Apr 2004 06:18:03 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3RAGYF13177; Tue, 27 Apr 2004 13:16:34 +0300 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , , Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408DB470.4090505@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 13:16:34 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 26 Apr 2004, Gargi Nalawade wrote: > > I can come up w/ 2 simple scenarios: > > a) you want fate sharing... i.e. intentionally tie afis so that when > > one fails the other does fail also. (both are required to provide a > > service for instance). > > b) you don't want to deal w/ the extra complexity of monitoring > > multiple substates and prefer to deal w/ a binary "works" / "broken". > > > > In both these examples which i consider rather realistic adding > > notifications/negotiation does not provide value. > > Give me one Provider who says that because IPv4 Unicast in their network > is needed for providing some IPv4 Multicast service, IPv4 unicast should > fail whenever IPv4 Multicast has an error or a CEASE notification. And when would such an error occur? If you have shared unicast/multicast infrastructure, pretty much never, unless both would be equally impacted. And when the topologies aren't congruent, then you will notice it in any case. I share Pedro's concerns about the applicability. If operators see it important to protect AFI/SAFIs from each other, something like "multisession" seems like an obvious choice. If there is an obvious choice, it will be deployed as well. It seems like we're talking about a solution which would become interesting either in the scenario where 1) operator is not (sufficiently interested) for doing something like multi-session BGP (but could be interested in something like this), or 2) operator doesn't want to wait for multi-session, and wants something sooner. Both of these scenarios seem very questionable to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 27 09:34:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00222 for ; Tue, 27 Apr 2004 09:34:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISjY-0007ZV-Dv for idr-archive@ietf.org; Tue, 27 Apr 2004 09:34:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISid-0007X6-00 for idr-archive@ietf.org; Tue, 27 Apr 2004 09:33:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIShn-0007Vg-00; Tue, 27 Apr 2004 09:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISa6-0001B8-0R; Tue, 27 Apr 2004 09:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISVD-0000He-Up for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:20:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29379 for ; Tue, 27 Apr 2004 09:19:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISV8-00051r-Fc for idr@ietf.org; Tue, 27 Apr 2004 09:19:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISUI-0004oJ-00 for idr@ietf.org; Tue, 27 Apr 2004 09:19:02 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BISTY-0004MK-00 for idr@ietf.org; Tue, 27 Apr 2004 09:18:16 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3RDHkl66515; Tue, 27 Apr 2004 06:17:46 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RDHfJ63618; Tue, 27 Apr 2004 06:17:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271317.i3RDHfJ63618@merlot.juniper.net> To: "Susan Hares" cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Your message of "Mon, 26 Apr 2004 13:53:43 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28916.1083071861.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 06:17:41 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sue, If one uses ORF to pass prefix limit, then I think there is no need to also exchange this limit in the BGP Open message - all you need to carry in the Open message is the Capability that indicates support for the prefix limit ORF type (and the appropriate AFI/SAFI). This is because of the way how ORF operates (quoting from the ORF spec): Consider a BGP speaker that advertises the Cooperative Route Filtering Capability indicating its willingness to receive a particular set of from its peer, and that receives the Cooperative Route Filtering Capability indicating the desire of the peer to send a particular set to the speaker. If for a given the intersection between these two sets are not-empty, the speaker SHOULD NOT advertise to the peer any routes with that prior to receiving from the peer any ROUTE-REFRESH message carrying that , where the message could be either without any ORF entries, or with one or more ORF entry and When-to-refresh field set to IMMEDIATE. If, on the other hand, for a given the intersection between these two sets is empty, the speaker SHOULD follow normal BGP procedures. In the above pay especial attention to the "speaker SHOULD NOT advertise" part. I am also a bit concerned with support for two ways of advertising the prefix limit: one via OFR and another via Dynamic Capabilities. Why narrowing this down to one is not enough ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 27 09:45:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00844 for ; Tue, 27 Apr 2004 09:45: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 1BISqR-0003gv-4d for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 09:41:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RDftwx014185 for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 09:41:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISjf-0002X3-EE for idr-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 09:34: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 JAA00250 for ; Tue, 27 Apr 2004 09:34:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISjZ-0007Zh-Rw for idr-web-archive@ietf.org; Tue, 27 Apr 2004 09:34:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISif-0007XK-00 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 09:33:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIShn-0007Vg-00; Tue, 27 Apr 2004 09:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISa6-0001B8-0R; Tue, 27 Apr 2004 09:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISVD-0000He-Up for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:20:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29379 for ; Tue, 27 Apr 2004 09:19:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISV8-00051r-Fc for idr@ietf.org; Tue, 27 Apr 2004 09:19:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISUI-0004oJ-00 for idr@ietf.org; Tue, 27 Apr 2004 09:19:02 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BISTY-0004MK-00 for idr@ietf.org; Tue, 27 Apr 2004 09:18:16 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3RDHkl66515; Tue, 27 Apr 2004 06:17:46 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RDHfJ63618; Tue, 27 Apr 2004 06:17:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271317.i3RDHfJ63618@merlot.juniper.net> To: "Susan Hares" cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Your message of "Mon, 26 Apr 2004 13:53:43 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28916.1083071861.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 06:17:41 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sue, If one uses ORF to pass prefix limit, then I think there is no need to also exchange this limit in the BGP Open message - all you need to carry in the Open message is the Capability that indicates support for the prefix limit ORF type (and the appropriate AFI/SAFI). This is because of the way how ORF operates (quoting from the ORF spec): Consider a BGP speaker that advertises the Cooperative Route Filtering Capability indicating its willingness to receive a particular set of from its peer, and that receives the Cooperative Route Filtering Capability indicating the desire of the peer to send a particular set to the speaker. If for a given the intersection between these two sets are not-empty, the speaker SHOULD NOT advertise to the peer any routes with that prior to receiving from the peer any ROUTE-REFRESH message carrying that , where the message could be either without any ORF entries, or with one or more ORF entry and When-to-refresh field set to IMMEDIATE. If, on the other hand, for a given the intersection between these two sets is empty, the speaker SHOULD follow normal BGP procedures. In the above pay especial attention to the "speaker SHOULD NOT advertise" part. I am also a bit concerned with support for two ways of advertising the prefix limit: one via OFR and another via Dynamic Capabilities. Why narrowing this down to one is not enough ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 27 09:47:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00996 for ; Tue, 27 Apr 2004 09:47:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISw8-0000SB-Ed for idr-archive@ietf.org; Tue, 27 Apr 2004 09:47:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISv9-0000OP-00 for idr-archive@ietf.org; Tue, 27 Apr 2004 09:46:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BISuI-0000Lg-00; Tue, 27 Apr 2004 09:45:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISqX-0003hf-84; Tue, 27 Apr 2004 09:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISjh-0002XB-J8 for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:34:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00253 for ; Tue, 27 Apr 2004 09:34:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISjb-0007a3-Vg for idr@ietf.org; Tue, 27 Apr 2004 09:34:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISij-0007Xr-00 for idr@ietf.org; Tue, 27 Apr 2004 09:33:57 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BISiQ-0007WB-00 for idr@ietf.org; Tue, 27 Apr 2004 09:33:38 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3RDX8Bm020529; Tue, 27 Apr 2004 06:33:08 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RDX8J64920; Tue, 27 Apr 2004 06:33:08 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271333.i3RDX8J64920@merlot.juniper.net> To: Michael Dell cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Your message of "Tue, 27 Apr 2004 14:20:55 BST." <53F74F5A7B94D511841C00B0D0AB16F802B138F3@baker.datcon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30635.1083072787.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 06:33:07 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Mike, > Yakov > > I have no particular comments on or issues with the draft. However, we were > slightly surprised by the time difference between this draft being published > and then moving to last call - about 2 minutes by my count. I can't see any > details on what is motivating this draft in the proceedings of the last > couple of IETF meetings. > > Apologies if I'm the only reader of this list that doesn't know the history > behind this modification, but perhaps you could summarise for me, either on > or off list? The main purpose of this draft is to update the current BGP Route Reflector spec to document how BGP route selection is done in the presence of BGP Route Reflectors. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 27 10:03:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01711 for ; Tue, 27 Apr 2004 10:03: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 1BIT9q-0007Su-UI for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 10:02:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RE1wCW028672 for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 10:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISwF-00056X-IW for idr-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 09:47: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 JAA01020 for ; Tue, 27 Apr 2004 09:47:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISw9-0000SM-QJ for idr-web-archive@ietf.org; Tue, 27 Apr 2004 09:47:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISvA-0000Oe-00 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 09:46:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BISuI-0000Lg-00; Tue, 27 Apr 2004 09:45:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISqX-0003hf-84; Tue, 27 Apr 2004 09:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISjh-0002XB-J8 for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:34:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00253 for ; Tue, 27 Apr 2004 09:34:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISjb-0007a3-Vg for idr@ietf.org; Tue, 27 Apr 2004 09:34:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISij-0007Xr-00 for idr@ietf.org; Tue, 27 Apr 2004 09:33:57 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BISiQ-0007WB-00 for idr@ietf.org; Tue, 27 Apr 2004 09:33:38 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3RDX8Bm020529; Tue, 27 Apr 2004 06:33:08 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RDX8J64920; Tue, 27 Apr 2004 06:33:08 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271333.i3RDX8J64920@merlot.juniper.net> To: Michael Dell cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Your message of "Tue, 27 Apr 2004 14:20:55 BST." <53F74F5A7B94D511841C00B0D0AB16F802B138F3@baker.datcon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30635.1083072787.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 06:33:07 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Mike, > Yakov > > I have no particular comments on or issues with the draft. However, we were > slightly surprised by the time difference between this draft being published > and then moving to last call - about 2 minutes by my count. I can't see any > details on what is motivating this draft in the proceedings of the last > couple of IETF meetings. > > Apologies if I'm the only reader of this list that doesn't know the history > behind this modification, but perhaps you could summarise for me, either on > or off list? The main purpose of this draft is to update the current BGP Route Reflector spec to document how BGP route selection is done in the presence of BGP Route Reflectors. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 27 10:34:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04244 for ; Tue, 27 Apr 2004 10:34:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITeq-0002fb-MA for idr-archive@ietf.org; Tue, 27 Apr 2004 10:34:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITe3-0002d6-00 for idr-archive@ietf.org; Tue, 27 Apr 2004 10:33:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BITdR-0002Zt-00; Tue, 27 Apr 2004 10:32:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITY5-0008B6-Ii; Tue, 27 Apr 2004 10: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 1BITRH-00064e-4T for idr@optimus.ietf.org; Tue, 27 Apr 2004 10:19:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03319 for ; Tue, 27 Apr 2004 10:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITRA-00024l-Sz for idr@ietf.org; Tue, 27 Apr 2004 10:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITQE-00022g-00 for idr@ietf.org; Tue, 27 Apr 2004 10:18:54 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BITPL-0001yt-00 for idr@ietf.org; Tue, 27 Apr 2004 10:18:00 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9722F2D4836 for ; Tue, 27 Apr 2004 10:17:27 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36326-01-26 for ; Tue, 27 Apr 2004 10:17:15 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5FDF72D481B for ; Tue, 27 Apr 2004 10:17:15 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQsWiIwjxNZgRFGRyCV7JJGht496AACB2XA From: "Susan Hares" To: "Yakov Rekhter" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 10:17:15 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Narrowing down to one would be fine. Sue -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Tuesday, April 27, 2004 9:18 AM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document=20 Sue, If one uses ORF to pass prefix limit, then I think there is no need to also exchange this limit in the BGP Open message - all you need to carry in the Open message is the Capability that indicates = support for the prefix limit ORF type (and the appropriate AFI/SAFI). This is because of the way how ORF operates (quoting from the ORF spec): Consider a BGP speaker that advertises the Cooperative Route = Filtering Capability indicating its willingness to receive a particular set of from its peer, and that receives the = Cooperative Route Filtering Capability indicating the desire of the peer to send = a particular set to the speaker. If for a given the intersection between these two sets are not-empty, = the speaker SHOULD NOT advertise to the peer any routes with that prior to receiving from the peer any ROUTE-REFRESH message carrying that , where the message could be either without any ORF entries, or with one or more ORF entry and When-to-refresh field set to IMMEDIATE. If, on the other hand, for a given the intersection between these two sets is empty, the speaker SHOULD follow normal BGP procedures. In the above pay especial attention to the "speaker SHOULD NOT = advertise"=20 part. I am also a bit concerned with support for two ways of advertising the prefix limit: one via OFR and another via Dynamic Capabilities. Why narrowing this down to one is not enough ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 27 10:46:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04797 for ; Tue, 27 Apr 2004 10:46: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 1BITiD-0002Jo-5i for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 10:37:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3REbTHe008907 for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 10:37:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITey-0001Ra-La for idr-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 10:34: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 KAA04261 for ; Tue, 27 Apr 2004 10:34:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITer-0002fl-W1 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 10:34:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITe5-0002dK-00 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 10:33:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BITdR-0002Zt-00; Tue, 27 Apr 2004 10:32:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITY5-0008B6-Ii; Tue, 27 Apr 2004 10: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 1BITRH-00064e-4T for idr@optimus.ietf.org; Tue, 27 Apr 2004 10:19:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03319 for ; Tue, 27 Apr 2004 10:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITRA-00024l-Sz for idr@ietf.org; Tue, 27 Apr 2004 10:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITQE-00022g-00 for idr@ietf.org; Tue, 27 Apr 2004 10:18:54 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BITPL-0001yt-00 for idr@ietf.org; Tue, 27 Apr 2004 10:18:00 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9722F2D4836 for ; Tue, 27 Apr 2004 10:17:27 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36326-01-26 for ; Tue, 27 Apr 2004 10:17:15 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5FDF72D481B for ; Tue, 27 Apr 2004 10:17:15 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQsWiIwjxNZgRFGRyCV7JJGht496AACB2XA From: "Susan Hares" To: "Yakov Rekhter" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 10:17:15 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Narrowing down to one would be fine. Sue -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Tuesday, April 27, 2004 9:18 AM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document=20 Sue, If one uses ORF to pass prefix limit, then I think there is no need to also exchange this limit in the BGP Open message - all you need to carry in the Open message is the Capability that indicates = support for the prefix limit ORF type (and the appropriate AFI/SAFI). This is because of the way how ORF operates (quoting from the ORF spec): Consider a BGP speaker that advertises the Cooperative Route = Filtering Capability indicating its willingness to receive a particular set of from its peer, and that receives the = Cooperative Route Filtering Capability indicating the desire of the peer to send = a particular set to the speaker. If for a given the intersection between these two sets are not-empty, = the speaker SHOULD NOT advertise to the peer any routes with that prior to receiving from the peer any ROUTE-REFRESH message carrying that , where the message could be either without any ORF entries, or with one or more ORF entry and When-to-refresh field set to IMMEDIATE. If, on the other hand, for a given the intersection between these two sets is empty, the speaker SHOULD follow normal BGP procedures. In the above pay especial attention to the "speaker SHOULD NOT = advertise"=20 part. I am also a bit concerned with support for two ways of advertising the prefix limit: one via OFR and another via Dynamic Capabilities. Why narrowing this down to one is not enough ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Apr 27 11:24:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07088 for ; Tue, 27 Apr 2004 11:24:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIURI-0005Xt-8Q for idr-archive@ietf.org; Tue, 27 Apr 2004 11:24:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUQY-0005Un-00 for idr-archive@ietf.org; Tue, 27 Apr 2004 11:23:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIUQ0-0005Pk-00; Tue, 27 Apr 2004 11:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUIY-0001LH-KW; Tue, 27 Apr 2004 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUGd-0000ws-3D for idr@optimus.ietf.org; Tue, 27 Apr 2004 11:13:03 -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 LAA06409 for ; Tue, 27 Apr 2004 11:13:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUGa-0004oM-5o for idr@ietf.org; Tue, 27 Apr 2004 11:13:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUFg-0004lK-00 for idr@ietf.org; Tue, 27 Apr 2004 11:12:05 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BIUEr-0004ej-00 for idr@ietf.org; Tue, 27 Apr 2004 11:11:13 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3RFAfBm020811; Tue, 27 Apr 2004 08:10:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RFAfJ73229; Tue, 27 Apr 2004 08:10:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271510.i3RFAfJ73229@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Your message of "Thu, 22 Apr 2004 12:44:26 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42644.1083078641.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 08:10:41 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, > On Fri, 16 Apr 2004, Yakov Rekhter wrote: > > During the Last Call it would be greatly appreciated if folks would > > read the document and comment on it to the IDR mailing list. In > > other words, we need "yes, looks good" or "should fix this and > > that", not just silence. > > In general, I think this should be rather close to being ready for > going forward. > > A few quick comments: > > - the text could use a lot more updates, but is readable as it is. > > - where are the implementation & interop reports? Enke is working on it (see his e-mail to the IDR mailing list on 4/14/2004). > - several ID-nits or other process issues must be fixed, at least: > o Status of this memo, Abstract, etc. must be unnumbered sections > (typically Introduction is section number 1) ok. > o No references in the abstract. ok. > o One cannot have normative references to documents of lower > maturity level. I suggest moving everything except [1] (or > maybe also [7]) to a new Informational References section. Correct - [1] should go into the Normative Reference section, the rest should go into the Non-normative Reference section. > o The document should probably say (in Abstract and Introduction) > that this document Obsoletes both 2796 and 1966 (note 2796 only > Updates 1966, which was probably a bug.)? Ok. > o Standard IPR statement is needed at the end even if there is is no > IPR. The date in the copyright statement is 4 years old as well.. ok. > o every empty line in this memo is duplicated (due to flawed > DOS/WINDOWS -> Unix conversion?) ok. > - food for thought: should we kill two birds in one stone, and also > declare RFC1863 ("A BGP/IDRP Route Server alternative to a full > mesh routing") historic? Is that useful anymore? This is a good question. May I suggest you'll bring it up to the IDR mailing list after we'll finish the WG Last Call on this document (as it deserves discussion on its own). > - A few rewordings I spotted (I grew bored with the text soon after > the abstract, as there would have been a lot of changes): > > Currently in the Internet BGP > deployments are configured such that that all BGP speakers within a > single AS must be fully meshed so that any external routing > information must be re-distributed to all other routers within that > AS. > > ==> s/Currently in the Internet BGP deployments are configured such > that that/Typically/ (the same in the Introduction) > > information, as is common in many of todays internet networks. > > ==> s/todays internet/today's Internet/ Sure. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Apr 27 11:46:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08232 for ; Tue, 27 Apr 2004 11:46:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUgt-00074q-Pj for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 11:40:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RFeBWY027200 for idr-archive@odin.ietf.org; Tue, 27 Apr 2004 11:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIURM-0002rI-JJ for idr-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 11:24: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 LAA07115 for ; Tue, 27 Apr 2004 11:24:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIURJ-0005Y5-NR for idr-web-archive@ietf.org; Tue, 27 Apr 2004 11:24:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUQa-0005V1-00 for idr-web-archive@ietf.org; Tue, 27 Apr 2004 11:23:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIUQ0-0005Pk-00; Tue, 27 Apr 2004 11:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUIY-0001LH-KW; Tue, 27 Apr 2004 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUGd-0000ws-3D for idr@optimus.ietf.org; Tue, 27 Apr 2004 11:13:03 -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 LAA06409 for ; Tue, 27 Apr 2004 11:13:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUGa-0004oM-5o for idr@ietf.org; Tue, 27 Apr 2004 11:13:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUFg-0004lK-00 for idr@ietf.org; Tue, 27 Apr 2004 11:12:05 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BIUEr-0004ej-00 for idr@ietf.org; Tue, 27 Apr 2004 11:11:13 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3RFAfBm020811; Tue, 27 Apr 2004 08:10:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RFAfJ73229; Tue, 27 Apr 2004 08:10:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271510.i3RFAfJ73229@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Your message of "Thu, 22 Apr 2004 12:44:26 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42644.1083078641.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 08:10:41 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, > On Fri, 16 Apr 2004, Yakov Rekhter wrote: > > During the Last Call it would be greatly appreciated if folks would > > read the document and comment on it to the IDR mailing list. In > > other words, we need "yes, looks good" or "should fix this and > > that", not just silence. > > In general, I think this should be rather close to being ready for > going forward. > > A few quick comments: > > - the text could use a lot more updates, but is readable as it is. > > - where are the implementation & interop reports? Enke is working on it (see his e-mail to the IDR mailing list on 4/14/2004). > - several ID-nits or other process issues must be fixed, at least: > o Status of this memo, Abstract, etc. must be unnumbered sections > (typically Introduction is section number 1) ok. > o No references in the abstract. ok. > o One cannot have normative references to documents of lower > maturity level. I suggest moving everything except [1] (or > maybe also [7]) to a new Informational References section. Correct - [1] should go into the Normative Reference section, the rest should go into the Non-normative Reference section. > o The document should probably say (in Abstract and Introduction) > that this document Obsoletes both 2796 and 1966 (note 2796 only > Updates 1966, which was probably a bug.)? Ok. > o Standard IPR statement is needed at the end even if there is is no > IPR. The date in the copyright statement is 4 years old as well.. ok. > o every empty line in this memo is duplicated (due to flawed > DOS/WINDOWS -> Unix conversion?) ok. > - food for thought: should we kill two birds in one stone, and also > declare RFC1863 ("A BGP/IDRP Route Server alternative to a full > mesh routing") historic? Is that useful anymore? This is a good question. May I suggest you'll bring it up to the IDR mailing list after we'll finish the WG Last Call on this document (as it deserves discussion on its own). > - A few rewordings I spotted (I grew bored with the text soon after > the abstract, as there would have been a lot of changes): > > Currently in the Internet BGP > deployments are configured such that that all BGP speakers within a > single AS must be fully meshed so that any external routing > information must be re-distributed to all other routers within that > AS. > > ==> s/Currently in the Internet BGP deployments are configured such > that that/Typically/ (the same in the Introduction) > > information, as is common in many of todays internet networks. > > ==> s/todays internet/today's Internet/ Sure. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 11:56:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23524 for ; Wed, 28 Apr 2004 11:56:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrPs-00026U-EF for idr-archive@ietf.org; Wed, 28 Apr 2004 11:56:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrNA-0001X1-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 11:53:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrLp-0001JL-00; Wed, 28 Apr 2004 11:51:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrKM-0002oa-JB; Wed, 28 Apr 2004 11: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 1BIr1e-00023K-Jb; Wed, 28 Apr 2004 11:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqt7-0000C9-2q for idr@optimus.ietf.org; Wed, 28 Apr 2004 11:22:17 -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 LAA21172 for ; Wed, 28 Apr 2004 11:22:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqt4-0006Si-TT for idr@ietf.org; Wed, 28 Apr 2004 11:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqs6-0006OU-00 for idr@ietf.org; Wed, 28 Apr 2004 11:21:15 -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 1BIqr6-0006HO-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 07:31:38 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFJgW9008270; Wed, 28 Apr 2004 08:19:42 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06341; Wed, 28 Apr 2004 11:19:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200404151359.i3FDxsJ92103@merlot.juniper.net> References: <200404151359.i3FDxsJ92103@merlot.juniper.net> To: Yakov Rekhter From: "John G. Scudder" Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:19:59 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 (Following up to original thread for completeness.) I don't think that the draft as it stands is appropriate as a WG doc because it's rather too complex. As noted in my other message, we've submitted another draft, draft-keyur-prefixlimit-orf-00, which represents an alternative approach to achieving the same goals. Regards, --John At 6:59 AM -0700 4/15/04, Yakov Rekhter wrote: >Folks, > >We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt >as an IDR WG document. Please send comments to the list. The deadline >for comments is April 29, 2004. > >Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 11:56:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23553 for ; Wed, 28 Apr 2004 11:56:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrPt-00026n-OG for idr-archive@ietf.org; Wed, 28 Apr 2004 11:56:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrNC-0001XO-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 11:53:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrLp-0001JL-01; Wed, 28 Apr 2004 11:51:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrJe-0002nK-Tx; Wed, 28 Apr 2004 11:49:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr1d-000239-Fv; Wed, 28 Apr 2004 11:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqsH-0008Uv-0n for idr@optimus.ietf.org; Wed, 28 Apr 2004 11:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21161 for ; Wed, 28 Apr 2004 11:21:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqsE-0006PI-Pj for idr@ietf.org; Wed, 28 Apr 2004 11:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqrL-0006Lg-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:28 -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 1BIqr5-0006HO-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 07:31:36 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFJeW9008210 for ; Wed, 28 Apr 2004 08:19:41 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06338 for ; Wed, 28 Apr 2004 11:19:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] draft-keyur-prefixlimit-orf-00 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, 28 Apr 2004 11:19:27 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, As others have noted, while the underlying goal of draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the actual mechanisms proposed are more complex than is necessary. We've written another draft which we think provides the needed functionality with less complexity, along the lines of what I suggested at the meeting in Minneapolis. In summary we introduce a new ORF-type which carries a 32 bit prefix limit, and also use the PERMIT/DENY flag to signal whether enforcement of the limit will be done by dropping the session or not. The draft is a tad over four pages plus six pages of IETF boilerplate. The draft has been submitted as an I-D. Until it's available in the usual places, you can find it at ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt Discussion of the draft would be welcome. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 12:19:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25395 for ; Wed, 28 Apr 2004 12:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrb0-00049L-OX for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SG7cuo015947 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrPw-0001KJ-Gk for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:56: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 LAA23552 for ; Wed, 28 Apr 2004 11:56:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrPt-00026g-Or for idr-web-archive@ietf.org; Wed, 28 Apr 2004 11:56:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrNC-0001XG-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 11:53:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrLp-0001JL-00; Wed, 28 Apr 2004 11:51:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrKM-0002oa-JB; Wed, 28 Apr 2004 11: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 1BIr1e-00023K-Jb; Wed, 28 Apr 2004 11:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqt7-0000C9-2q for idr@optimus.ietf.org; Wed, 28 Apr 2004 11:22:17 -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 LAA21172 for ; Wed, 28 Apr 2004 11:22:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqt4-0006Si-TT for idr@ietf.org; Wed, 28 Apr 2004 11:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqs6-0006OU-00 for idr@ietf.org; Wed, 28 Apr 2004 11:21:15 -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 1BIqr6-0006HO-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 07:31:38 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFJgW9008270; Wed, 28 Apr 2004 08:19:42 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06341; Wed, 28 Apr 2004 11:19:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200404151359.i3FDxsJ92103@merlot.juniper.net> References: <200404151359.i3FDxsJ92103@merlot.juniper.net> To: Yakov Rekhter From: "John G. Scudder" Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:19:59 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 (Following up to original thread for completeness.) I don't think that the draft as it stands is appropriate as a WG doc because it's rather too complex. As noted in my other message, we've submitted another draft, draft-keyur-prefixlimit-orf-00, which represents an alternative approach to achieving the same goals. Regards, --John At 6:59 AM -0700 4/15/04, Yakov Rekhter wrote: >Folks, > >We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt >as an IDR WG document. Please send comments to the list. The deadline >for comments is April 29, 2004. > >Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 12:19:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25413 for ; Wed, 28 Apr 2004 12:19: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 1BIrb0-00049Z-R3 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SG7cJL015960 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrPx-0001KL-Fv for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23575 for ; Wed, 28 Apr 2004 11:56:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrPu-00026y-Nz for idr-web-archive@ietf.org; Wed, 28 Apr 2004 11:56:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrNE-0001Xe-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 11:53:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrLp-0001JL-01; Wed, 28 Apr 2004 11:51:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrJe-0002nK-Tx; Wed, 28 Apr 2004 11:49:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr1d-000239-Fv; Wed, 28 Apr 2004 11:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqsH-0008Uv-0n for idr@optimus.ietf.org; Wed, 28 Apr 2004 11:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21161 for ; Wed, 28 Apr 2004 11:21:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqsE-0006PI-Pj for idr@ietf.org; Wed, 28 Apr 2004 11:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqrL-0006Lg-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:28 -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 1BIqr5-0006HO-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 07:31:36 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFJeW9008210 for ; Wed, 28 Apr 2004 08:19:41 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06338 for ; Wed, 28 Apr 2004 11:19:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] draft-keyur-prefixlimit-orf-00 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, 28 Apr 2004 11:19:27 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, As others have noted, while the underlying goal of draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the actual mechanisms proposed are more complex than is necessary. We've written another draft which we think provides the needed functionality with less complexity, along the lines of what I suggested at the meeting in Minneapolis. In summary we introduce a new ORF-type which carries a 32 bit prefix limit, and also use the PERMIT/DENY flag to signal whether enforcement of the limit will be done by dropping the session or not. The draft is a tad over four pages plus six pages of IETF boilerplate. The draft has been submitted as an I-D. Until it's available in the usual places, you can find it at ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt Discussion of the draft would be welcome. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 12:30:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26620 for ; Wed, 28 Apr 2004 12:30:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrwv-00058A-TL for idr-archive@ietf.org; Wed, 28 Apr 2004 12:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrw1-00051w-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 12:29:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIrvC-0004uv-00; Wed, 28 Apr 2004 12:28:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrm1-0007z8-06; Wed, 28 Apr 2004 12:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrVA-00034W-30 for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:01:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24513 for ; Wed, 28 Apr 2004 12:01:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrV7-0002rD-KP for idr@ietf.org; Wed, 28 Apr 2004 12:01:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrUB-0002lt-00 for idr@ietf.org; Wed, 28 Apr 2004 12:00:36 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BIrTF-0002cf-00 for idr@ietf.org; Wed, 28 Apr 2004 11:59:37 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWW00MB71JSW5@firewall.mci.com> for idr@ietf.org; Wed, 28 Apr 2004 15:55:04 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWW00B011GDNE@pmismtp04.mcilink.com>; Wed, 28 Apr 2004 15:55:04 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWW00A4Z1JCP8@pmismtp04.mcilink.com>; Wed, 28 Apr 2004 15:54:49 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] Soft-Notify as an IDR WG document In-reply-to: To: "'Pekka Savola'" , "'Gargi Nalawade'" Cc: "'Pedro Roque Marques'" , idr@ietf.org, "'Yakov Rekhter'" Message-id: <002601c42d39$22a08ef0$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:54:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The response to this particular thread has been particularly = interesting.=20 So long the dominant story from this community has been to put all new services and new features on the existing BGP protocol, which has an established base, and keep the operator's world easy and simple. The argument was that the vendors were good enough to handle all the complexities in the protocol implementation and the operators need not = worry about code issues as much. So the (over)loading of BGP continues. Some people, realizing that the BGP train was coming too fast and too strong, stopped arguing. Now, here is this thread, where a part of the same community is = suggesting that giving individual soft control to each AFI/SAFI pair would make BGP protocol implementation more complicated than necessary and we should = push the complexity to the operator world. That is fine and in some ways = sane, but in most ways confusing.=20 If the community has already made its mind that BGP is going to carry = most of the services, the vendor community has accepted to undertake that incremental complexity and the operators have accepted to live with the risk, then resisting this draft from going to WG, is a mixed signal. If everyone HAS to live with multiple AFI/SAFI in the same session, they = might as well get their control and not think about how many sets of sessions = they should run in their infrastructure. If the BGP session has to be split it should be split across the infrastructure and service boundary. The infrastructure layer should run hardened well tested BGP code and the service layer could run new loaded = BGP (or ??) code which will have individual control of individual services built-in. -Parantap -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Pekka Savola Sent: Tuesday, April 27, 2004 6:17 AM To: Gargi Nalawade Cc: Pedro Roque Marques; idr@ietf.org; Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document On Mon, 26 Apr 2004, Gargi Nalawade wrote: > > I can come up w/ 2 simple scenarios: > > a) you want fate sharing... i.e. intentionally tie afis so that when > > one fails the other does fail also. (both are required to provide a > > service for instance). > > b) you don't want to deal w/ the extra complexity of monitoring > > multiple substates and prefer to deal w/ a binary "works" / = "broken". > >=20 > > In both these examples which i consider rather realistic adding > > notifications/negotiation does not provide value. >=20 > Give me one Provider who says that because IPv4 Unicast in their = network > is needed for providing some IPv4 Multicast service, IPv4 unicast = should > fail whenever IPv4 Multicast has an error or a CEASE notification. And when would such an error occur? If you have shared=20 unicast/multicast infrastructure, pretty much never, unless both would=20 be equally impacted. And when the topologies aren't congruent, then=20 you will notice it in any case. I share Pedro's concerns about the applicability. If operators see it important to protect AFI/SAFIs from each other, something like "multisession" seems like an obvious choice. If there is an obvious choice, it will be deployed as well. It seems like we're talking about a solution which would become=20 interesting either in the scenario where 1) operator is not=20 (sufficiently interested) for doing something like multi-session BGP=20 (but could be interested in something like this), or 2) operator=20 doesn't want to wait for multi-session, and wants something sooner. Both of these scenarios seem very questionable to me. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 12:48:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27873 for ; Wed, 28 Apr 2004 12:48: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 1BIs7a-0004I9-B2 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 12:41:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGfIOC016457 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 12:41:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrx0-00021r-KZ for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:30: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 MAA26648 for ; Wed, 28 Apr 2004 12:30:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrwx-00058L-Le for idr-web-archive@ietf.org; Wed, 28 Apr 2004 12:30:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrw3-00052C-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 12:29:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIrvC-0004uv-00; Wed, 28 Apr 2004 12:28:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrm1-0007z8-06; Wed, 28 Apr 2004 12:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrVA-00034W-30 for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:01:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24513 for ; Wed, 28 Apr 2004 12:01:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrV7-0002rD-KP for idr@ietf.org; Wed, 28 Apr 2004 12:01:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrUB-0002lt-00 for idr@ietf.org; Wed, 28 Apr 2004 12:00:36 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BIrTF-0002cf-00 for idr@ietf.org; Wed, 28 Apr 2004 11:59:37 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWW00MB71JSW5@firewall.mci.com> for idr@ietf.org; Wed, 28 Apr 2004 15:55:04 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWW00B011GDNE@pmismtp04.mcilink.com>; Wed, 28 Apr 2004 15:55:04 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWW00A4Z1JCP8@pmismtp04.mcilink.com>; Wed, 28 Apr 2004 15:54:49 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] Soft-Notify as an IDR WG document In-reply-to: To: "'Pekka Savola'" , "'Gargi Nalawade'" Cc: "'Pedro Roque Marques'" , idr@ietf.org, "'Yakov Rekhter'" Message-id: <002601c42d39$22a08ef0$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:54:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The response to this particular thread has been particularly = interesting.=20 So long the dominant story from this community has been to put all new services and new features on the existing BGP protocol, which has an established base, and keep the operator's world easy and simple. The argument was that the vendors were good enough to handle all the complexities in the protocol implementation and the operators need not = worry about code issues as much. So the (over)loading of BGP continues. Some people, realizing that the BGP train was coming too fast and too strong, stopped arguing. Now, here is this thread, where a part of the same community is = suggesting that giving individual soft control to each AFI/SAFI pair would make BGP protocol implementation more complicated than necessary and we should = push the complexity to the operator world. That is fine and in some ways = sane, but in most ways confusing.=20 If the community has already made its mind that BGP is going to carry = most of the services, the vendor community has accepted to undertake that incremental complexity and the operators have accepted to live with the risk, then resisting this draft from going to WG, is a mixed signal. If everyone HAS to live with multiple AFI/SAFI in the same session, they = might as well get their control and not think about how many sets of sessions = they should run in their infrastructure. If the BGP session has to be split it should be split across the infrastructure and service boundary. The infrastructure layer should run hardened well tested BGP code and the service layer could run new loaded = BGP (or ??) code which will have individual control of individual services built-in. -Parantap -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Pekka Savola Sent: Tuesday, April 27, 2004 6:17 AM To: Gargi Nalawade Cc: Pedro Roque Marques; idr@ietf.org; Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document On Mon, 26 Apr 2004, Gargi Nalawade wrote: > > I can come up w/ 2 simple scenarios: > > a) you want fate sharing... i.e. intentionally tie afis so that when > > one fails the other does fail also. (both are required to provide a > > service for instance). > > b) you don't want to deal w/ the extra complexity of monitoring > > multiple substates and prefer to deal w/ a binary "works" / = "broken". > >=20 > > In both these examples which i consider rather realistic adding > > notifications/negotiation does not provide value. >=20 > Give me one Provider who says that because IPv4 Unicast in their = network > is needed for providing some IPv4 Multicast service, IPv4 unicast = should > fail whenever IPv4 Multicast has an error or a CEASE notification. And when would such an error occur? If you have shared=20 unicast/multicast infrastructure, pretty much never, unless both would=20 be equally impacted. And when the topologies aren't congruent, then=20 you will notice it in any case. I share Pedro's concerns about the applicability. If operators see it important to protect AFI/SAFIs from each other, something like "multisession" seems like an obvious choice. If there is an obvious choice, it will be deployed as well. It seems like we're talking about a solution which would become=20 interesting either in the scenario where 1) operator is not=20 (sufficiently interested) for doing something like multi-session BGP=20 (but could be interested in something like this), or 2) operator=20 doesn't want to wait for multi-session, and wants something sooner. Both of these scenarios seem very questionable to me. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 13:03:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28884 for ; Wed, 28 Apr 2004 13:03:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsSq-00073W-Nx for idr-archive@ietf.org; Wed, 28 Apr 2004 13:03:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsRs-0006ya-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:02:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsQu-0006te-00; Wed, 28 Apr 2004 13:01:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCF-0005JO-5t; Wed, 28 Apr 2004 12:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs5E-0003VI-5s for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:38:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27230 for ; Wed, 28 Apr 2004 12:38:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs5B-0005XF-5a for idr@ietf.org; Wed, 28 Apr 2004 12:38:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs4F-0005VW-00 for idr@ietf.org; Wed, 28 Apr 2004 12:37:51 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIs3Q-0005S5-00 for idr@ietf.org; Wed, 28 Apr 2004 12:37:00 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 58EFB2D485B for ; Wed, 28 Apr 2004 12:36:26 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 75082-01-13 for ; Wed, 28 Apr 2004 12:36:14 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3FB802D4869 for ; Wed, 28 Apr 2004 12:36:14 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Message-ID: Thread-Topic: [Idr] draft-keyur-prefixlimit-orf-00 Thread-Index: AcQtOGqpfZ3Y41LETMSRslIG2LgcpAABdwRQ From: "Susan Hares" To: "John G. Scudder" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 12:36:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable John: Well this is amazing. Since you suggested the complexity... Perhaps you changed your mind.=20 We put the complex ORF policy in because you state Cisco did not support dynamic configuration.=20 In simplifying this, I do not find people wanting to go to an ORF policy. =20 Sue PS - your acknowledgement section is problematic. -----Original Message----- From: John G. Scudder [mailto:jgs@cisco.com] Sent: Wednesday, April 28, 2004 11:19 AM To: idr@ietf.org Subject: [Idr] draft-keyur-prefixlimit-orf-00 Folks, As others have noted, while the underlying goal of=20 draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the=20 actual mechanisms proposed are more complex than is necessary. We've written another draft which we think provides the needed=20 functionality with less complexity, along the lines of what I=20 suggested at the meeting in Minneapolis. In summary we introduce a=20 new ORF-type which carries a 32 bit prefix limit, and also use the=20 PERMIT/DENY flag to signal whether enforcement of the limit will be=20 done by dropping the session or not. The draft is a tad over four=20 pages plus six pages of IETF boilerplate. The draft has been submitted as an I-D. Until it's available in the=20 usual places, you can find it at=20 ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt Discussion of the draft would be welcome. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 13:06:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29219 for ; Wed, 28 Apr 2004 13:06:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsVs-0007IU-VX for idr-archive@ietf.org; Wed, 28 Apr 2004 13:06:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsUy-0007Ev-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:05:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsU8-0007B7-00; Wed, 28 Apr 2004 13:04:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsHw-0006Qf-LH; Wed, 28 Apr 2004 12:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISYH-0000Y2-OX for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:23: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 JAA29542 for ; Tue, 27 Apr 2004 09:23:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISYB-0005ln-9e for idr@ietf.org; Tue, 27 Apr 2004 09:23:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISXK-0005Xu-00 for idr@ietf.org; Tue, 27 Apr 2004 09:22:11 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BISWs-0005IF-00 for idr@ietf.org; Tue, 27 Apr 2004 09:21:42 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Apr 2004 14:21:13 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802B138F3@baker.datcon.co.uk> From: Michael Dell To: "'Yakov Rekhter'" , idr@ietf.org Subject: RE: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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, 27 Apr 2004 14:20:55 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Yakov I have no particular comments on or issues with the draft. However, we were slightly surprised by the time difference between this draft being published and then moving to last call - about 2 minutes by my count. I can't see any details on what is motivating this draft in the proceedings of the last couple of IETF meetings. Apologies if I'm the only reader of this list that doesn't know the history behind this modification, but perhaps you could summarise for me, either on or off list? Regards Mike Dell Networking Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8367 8501 E-mail: mike.dell@dataconnection.com Web: http://www.dataconnection.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: 16 April 2004 22:21 To: idr@ietf.org Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, During the Last Call it would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 13:36:09 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. - ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - - --OtherAccess-- - - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 13:15:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29732 for ; Wed, 28 Apr 2004 13:15:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIseT-00004b-01 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:15:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsdX-0007j0-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:14:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsca-0007gK-00; Wed, 28 Apr 2004 13:13:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsTb-0000Un-T7; Wed, 28 Apr 2004 13:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsES-0005if-N0 for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:48: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 MAA27913 for ; Wed, 28 Apr 2004 12:48:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsEP-0006DN-N4 for idr@ietf.org; Wed, 28 Apr 2004 12:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsDQ-00068H-00 for idr@ietf.org; Wed, 28 Apr 2004 12:47:21 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIsCp-00061U-00 for idr@ietf.org; Wed, 28 Apr 2004 12:46:43 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3SGkE5O024652; Wed, 28 Apr 2004 09:46:14 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3SGkEde024649; Wed, 28 Apr 2004 09:46:14 -0700 (PDT) Message-Id: <200404281646.i3SGkEde024649@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Parantap Lahiri Cc: idr@ietf.org, "'Yakov Rekhter'" Subject: RE: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <002601c42d39$22a08ef0$a3922799@mcilink.com> References: <002601c42d39$22a08ef0$a3922799@mcilink.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 28 Apr 2004 09:46:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Parantap Lahiri writes: > Now, here is this thread, where a part of the same community is > suggesting that giving individual soft control to each AFI/SAFI pair > would make BGP protocol implementation more complicated than > necessary and we should push the complexity to the operator > world. That is fine and in some ways sane, but in most ways > confusing. This is a misrepresentation of the argument. The point is that you cannot achieve individual control for afi/safi without adding the necessary diagnostics and support for tools and management on the operator side. Not to mention understanding of how mecanisms work. The multisession draft is nicer alternative for several reasons including the fact that it fits into the current management framework and follows a model understood by all. The point is not wether to achieve a given end goal but to find the approach that gets us there with less pain. and which can be built incrementally. As an operator i would expect you to be supportive of the need to consider the network management implications before picking a solution. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 13:22:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00436 for ; Wed, 28 Apr 2004 13:22:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIslN-0000bM-1l for idr-archive@ietf.org; Wed, 28 Apr 2004 13:22:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIskW-0000YJ-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:21:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsjq-0000VF-00; Wed, 28 Apr 2004 13:20:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsUb-0000vG-6b; Wed, 28 Apr 2004 13:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsIK-0006Wo-Bn for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:52: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 MAA28246 for ; Wed, 28 Apr 2004 12:52:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsIH-0006RX-9K for idr@ietf.org; Wed, 28 Apr 2004 12:52:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsHR-0006PR-00 for idr@ietf.org; Wed, 28 Apr 2004 12:51:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BIsGu-0006LX-00 for idr@ietf.org; Wed, 28 Apr 2004 12:50:56 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SGoNW9006923; Wed, 28 Apr 2004 09:50:23 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA10499; Wed, 28 Apr 2004 12:50:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: "Susan Hares" From: "John G. Scudder" Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Cc: Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 12:50:28 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sue, Sorry you feel that way. As you might imagine, I=20 have a different perspective, which is that I=20 tried to suggest a way to simplify the=20 specification, but instead found the -01 version=20 to be more complex. Since I clearly didn't=20 communicate the idea effectively enough at the=20 Minneapolis meeting it seemed like it would be=20 more productive to express it in the form of a=20 fully written specification instead of a list of=20 comments. If you haven't read=20 draft-keyur-prefixlimit-orf-00 then please do=20 (it's short). If having read it you do think=20 that it's more complex, I'd love to discuss the=20 reasons. Of course, I would also like to hear=20 what other members of the WG think. We'd be happy to make reasonable changes to the=20 acknowledgement section if you'd like to=20 communicate what the problem is, either on or off=20 list. Respectfully, --John At 12:36 PM -0400 4/28/04, Susan Hares wrote: >John: > >Well this is amazing. Since you suggested the complexity... >Perhaps you changed your mind. > >We put the complex ORF policy in because you state >Cisco did not support dynamic configuration. >In simplifying this, I do not find people wanting to >go to an ORF policy.=A0 > >Sue > >PS - your acknowledgement section is problematic. > >-----Original Message----- >From: John G. Scudder [mailto:jgs@cisco.com] >Sent: Wednesday, April 28, 2004 11:19 AM >To: idr@ietf.org >Subject: [Idr] draft-keyur-prefixlimit-orf-00 > > >Folks, > >As others have noted, while the underlying goal of >draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the >actual mechanisms proposed are more complex than is necessary. > >We've written another draft which we think provides the needed >functionality with less complexity, along the lines of what I >suggested at the meeting in Minneapolis. In summary we introduce a >new ORF-type which carries a 32 bit prefix limit, and also use the >PERMIT/DENY flag to signal whether enforcement of the limit will be >done by dropping the session or not. The draft is a tad over four >pages plus six pages of IETF boilerplate. > >The draft has been submitted as an I-D. Until it's available in the >usual places, you can find it at >ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt > >Discussion of the draft would be welcome. > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 13:23:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00562 for ; Wed, 28 Apr 2004 13:23: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 1BIsWO-0001h9-Sm for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SH6uih006516 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsSv-0000HL-LY for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:03:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28914 for ; Wed, 28 Apr 2004 13:03:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsSs-00073g-FX for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:03:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsRt-0006yo-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:02:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsQu-0006te-00; Wed, 28 Apr 2004 13:01:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCF-0005JO-5t; Wed, 28 Apr 2004 12:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs5E-0003VI-5s for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:38:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27230 for ; Wed, 28 Apr 2004 12:38:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs5B-0005XF-5a for idr@ietf.org; Wed, 28 Apr 2004 12:38:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs4F-0005VW-00 for idr@ietf.org; Wed, 28 Apr 2004 12:37:51 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIs3Q-0005S5-00 for idr@ietf.org; Wed, 28 Apr 2004 12:37:00 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 58EFB2D485B for ; Wed, 28 Apr 2004 12:36:26 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 75082-01-13 for ; Wed, 28 Apr 2004 12:36:14 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3FB802D4869 for ; Wed, 28 Apr 2004 12:36:14 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Message-ID: Thread-Topic: [Idr] draft-keyur-prefixlimit-orf-00 Thread-Index: AcQtOGqpfZ3Y41LETMSRslIG2LgcpAABdwRQ From: "Susan Hares" To: "John G. Scudder" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 12:36:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable John: Well this is amazing. Since you suggested the complexity... Perhaps you changed your mind.=20 We put the complex ORF policy in because you state Cisco did not support dynamic configuration.=20 In simplifying this, I do not find people wanting to go to an ORF policy. =20 Sue PS - your acknowledgement section is problematic. -----Original Message----- From: John G. Scudder [mailto:jgs@cisco.com] Sent: Wednesday, April 28, 2004 11:19 AM To: idr@ietf.org Subject: [Idr] draft-keyur-prefixlimit-orf-00 Folks, As others have noted, while the underlying goal of=20 draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the=20 actual mechanisms proposed are more complex than is necessary. We've written another draft which we think provides the needed=20 functionality with less complexity, along the lines of what I=20 suggested at the meeting in Minneapolis. In summary we introduce a=20 new ORF-type which carries a 32 bit prefix limit, and also use the=20 PERMIT/DENY flag to signal whether enforcement of the limit will be=20 done by dropping the session or not. The draft is a tad over four=20 pages plus six pages of IETF boilerplate. The draft has been submitted as an I-D. Until it's available in the=20 usual places, you can find it at=20 ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt Discussion of the draft would be welcome. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 13:25:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00884 for ; Wed, 28 Apr 2004 13:25:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsoc-0000xY-U5 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:25:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsny-0000qz-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:25:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsmv-0000kw-00; Wed, 28 Apr 2004 13:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsWZ-0001jl-8N; Wed, 28 Apr 2004 13:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsQ7-0008P8-GT for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28716 for ; Wed, 28 Apr 2004 13:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsQ4-0006ra-HM for idr@ietf.org; Wed, 28 Apr 2004 13:00:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsPB-0006p2-00 for idr@ietf.org; Wed, 28 Apr 2004 12:59:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIsOh-0006mF-00 for idr@ietf.org; Wed, 28 Apr 2004 12:58:59 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7C0042D4A05 for ; Wed, 28 Apr 2004 12:58:30 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74394-01-73 for ; Wed, 28 Apr 2004 12:58:17 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E95D02D4877 for ; Wed, 28 Apr 2004 12:58:17 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Message-ID: Thread-Topic: [Idr] draft-keyur-prefixlimit-orf-00 Thread-Index: AcQtQPIUe5/VlB+ZRma6+cq5bG02PAAACVhw From: "Susan Hares" To: "John G. Scudder" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 12:58:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable John: Read document before I sent the message.=20 Complexity came in -01 came in allowing ORFs as well as the global limits. We set it=20 up as an option and worked out the coordination deals So, we'll just trying to allow both methods. Capabilities and Dynamic capabilities provide a simple way to determine the 3 prefix limits: warning, stop receiving and disconnect per peer. The support of dynamic allows re-negotiation easily on a connection basis.=20 ORFs is too heavy weighted for that simple focus.=20 If we are trying to travel light, ORFs are like adding a 2 ton weight to your baggage.=20 Sue -----Original Message----- From: John G. Scudder [mailto:jgs@cisco.com] Sent: Wednesday, April 28, 2004 12:50 PM To: Susan Hares Cc: idr@ietf.org Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Sue, Sorry you feel that way. As you might imagine, I=20 have a different perspective, which is that I=20 tried to suggest a way to simplify the=20 specification, but instead found the -01 version=20 to be more complex. Since I clearly didn't=20 communicate the idea effectively enough at the=20 Minneapolis meeting it seemed like it would be=20 more productive to express it in the form of a=20 fully written specification instead of a list of=20 comments. If you haven't read=20 draft-keyur-prefixlimit-orf-00 then please do=20 (it's short). If having read it you do think=20 that it's more complex, I'd love to discuss the=20 reasons. Of course, I would also like to hear=20 what other members of the WG think. We'd be happy to make reasonable changes to the=20 acknowledgement section if you'd like to=20 communicate what the problem is, either on or off=20 list. Respectfully, --John At 12:36 PM -0400 4/28/04, Susan Hares wrote: >John: > >Well this is amazing. Since you suggested the complexity... >Perhaps you changed your mind. > >We put the complex ORF policy in because you state >Cisco did not support dynamic configuration. >In simplifying this, I do not find people wanting to >go to an ORF policy.=A0 > >Sue > >PS - your acknowledgement section is problematic. > >-----Original Message----- >From: John G. Scudder [mailto:jgs@cisco.com] >Sent: Wednesday, April 28, 2004 11:19 AM >To: idr@ietf.org >Subject: [Idr] draft-keyur-prefixlimit-orf-00 > > >Folks, > >As others have noted, while the underlying goal of >draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the >actual mechanisms proposed are more complex than is necessary. > >We've written another draft which we think provides the needed >functionality with less complexity, along the lines of what I >suggested at the meeting in Minneapolis. In summary we introduce a >new ORF-type which carries a 32 bit prefix limit, and also use the >PERMIT/DENY flag to signal whether enforcement of the limit will be >done by dropping the session or not. The draft is a tad over four >pages plus six pages of IETF boilerplate. > >The draft has been submitted as an I-D. Until it's available in the >usual places, you can find it at >ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt > >Discussion of the draft would be welcome. > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 13:30:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01351 for ; Wed, 28 Apr 2004 13:30: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 1BIslM-0005mr-Cr for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:22:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHMORD022240 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:22:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsVy-0001Mf-BC for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:06: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 NAA29247 for ; Wed, 28 Apr 2004 13:06:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsVv-0007Im-3X for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:06:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsV0-0007FB-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:05:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsU8-0007B7-00; Wed, 28 Apr 2004 13:04:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsHw-0006Qf-LH; Wed, 28 Apr 2004 12:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISYH-0000Y2-OX for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:23: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 JAA29542 for ; Tue, 27 Apr 2004 09:23:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISYB-0005ln-9e for idr@ietf.org; Tue, 27 Apr 2004 09:23:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISXK-0005Xu-00 for idr@ietf.org; Tue, 27 Apr 2004 09:22:11 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BISWs-0005IF-00 for idr@ietf.org; Tue, 27 Apr 2004 09:21:42 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Apr 2004 14:21:13 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802B138F3@baker.datcon.co.uk> From: Michael Dell To: "'Yakov Rekhter'" , idr@ietf.org Subject: RE: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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, 27 Apr 2004 14:20:55 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Yakov I have no particular comments on or issues with the draft. However, we were slightly surprised by the time difference between this draft being published and then moving to last call - about 2 minutes by my count. I can't see any details on what is motivating this draft in the proceedings of the last couple of IETF meetings. Apologies if I'm the only reader of this list that doesn't know the history behind this modification, but perhaps you could summarise for me, either on or off list? Regards Mike Dell Networking Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8367 8501 E-mail: mike.dell@dataconnection.com Web: http://www.dataconnection.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: 16 April 2004 22:21 To: idr@ietf.org Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, During the Last Call it would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 13:36:09 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. - ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - - --OtherAccess-- - - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 13:35:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01866 for ; Wed, 28 Apr 2004 13:35: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 1BIss8-0007Xd-2t for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:29:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHTOvQ028985 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIseY-0003zT-9K for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:15: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 NAA29764 for ; Wed, 28 Apr 2004 13:15:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIseV-00004u-2O for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:15:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsdY-0007jG-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:14:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsca-0007gK-00; Wed, 28 Apr 2004 13:13:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsTb-0000Un-T7; Wed, 28 Apr 2004 13:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsES-0005if-N0 for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:48: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 MAA27913 for ; Wed, 28 Apr 2004 12:48:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsEP-0006DN-N4 for idr@ietf.org; Wed, 28 Apr 2004 12:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsDQ-00068H-00 for idr@ietf.org; Wed, 28 Apr 2004 12:47:21 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIsCp-00061U-00 for idr@ietf.org; Wed, 28 Apr 2004 12:46:43 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3SGkE5O024652; Wed, 28 Apr 2004 09:46:14 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3SGkEde024649; Wed, 28 Apr 2004 09:46:14 -0700 (PDT) Message-Id: <200404281646.i3SGkEde024649@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Parantap Lahiri Cc: idr@ietf.org, "'Yakov Rekhter'" Subject: RE: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <002601c42d39$22a08ef0$a3922799@mcilink.com> References: <002601c42d39$22a08ef0$a3922799@mcilink.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 28 Apr 2004 09:46:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Parantap Lahiri writes: > Now, here is this thread, where a part of the same community is > suggesting that giving individual soft control to each AFI/SAFI pair > would make BGP protocol implementation more complicated than > necessary and we should push the complexity to the operator > world. That is fine and in some ways sane, but in most ways > confusing. This is a misrepresentation of the argument. The point is that you cannot achieve individual control for afi/safi without adding the necessary diagnostics and support for tools and management on the operator side. Not to mention understanding of how mecanisms work. The multisession draft is nicer alternative for several reasons including the fact that it fits into the current management framework and follows a model understood by all. The point is not wether to achieve a given end goal but to find the approach that gets us there with less pain. and which can be built incrementally. As an operator i would expect you to be supportive of the need to consider the network management implications before picking a solution. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 13:39:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02167 for ; Wed, 28 Apr 2004 13:39:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt1w-000274-8W for idr-archive@ietf.org; Wed, 28 Apr 2004 13:39:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt0x-000239-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:38:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIt0M-00020F-00; Wed, 28 Apr 2004 13:37:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIssj-0007kb-Ka; Wed, 28 Apr 2004 13:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsf9-00047t-6Z for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29890 for ; Wed, 28 Apr 2004 13:15:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsf5-00008l-VU for idr@ietf.org; Wed, 28 Apr 2004 13:15:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIseA-00001K-00 for idr@ietf.org; Wed, 28 Apr 2004 13:14:58 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BIscl-0007hT-00 for idr@ietf.org; Wed, 28 Apr 2004 13:13:32 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5508CA6EBA1; Wed, 28 Apr 2004 10:13:32 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09989-06; Wed, 28 Apr 2004 10:13:32 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 8A422A6EBA0; Wed, 28 Apr 2004 10:13:30 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id B1AB915D3C2; Wed, 28 Apr 2004 10:13:29 -0700 (PDT) To: yakov@juniper.net, skh@nexthop.com Cc: idr@ietf.org From: Enke Chen Message-Id: <20040428171329.B1AB915D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] draft-chen-bgp-avoid-transition-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, 28 Apr 2004 10:13:29 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Yakov and Sue: I would like to request that the draft be accepted as an IDR WG document. The draft was presented previosuly at an IDR meeting. The algorithm described in the draft has been deployed for several years. Thanks. -- Enke ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoid BGP Best Path Transition from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 13:44:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02573 for ; Wed, 28 Apr 2004 13:44: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 1BIssr-0007nU-QR for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:30:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHU9xs029967 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIslS-0005rW-26 for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:22: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 NAA00464 for ; Wed, 28 Apr 2004 13:22:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIslO-0000bh-Rg for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:22:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIskY-0000YY-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:21:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsjq-0000VF-00; Wed, 28 Apr 2004 13:20:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsUb-0000vG-6b; Wed, 28 Apr 2004 13:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsIK-0006Wo-Bn for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:52: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 MAA28246 for ; Wed, 28 Apr 2004 12:52:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsIH-0006RX-9K for idr@ietf.org; Wed, 28 Apr 2004 12:52:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsHR-0006PR-00 for idr@ietf.org; Wed, 28 Apr 2004 12:51:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BIsGu-0006LX-00 for idr@ietf.org; Wed, 28 Apr 2004 12:50:56 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SGoNW9006923; Wed, 28 Apr 2004 09:50:23 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA10499; Wed, 28 Apr 2004 12:50:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: "Susan Hares" From: "John G. Scudder" Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Cc: Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 12:50:28 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sue, Sorry you feel that way. As you might imagine, I=20 have a different perspective, which is that I=20 tried to suggest a way to simplify the=20 specification, but instead found the -01 version=20 to be more complex. Since I clearly didn't=20 communicate the idea effectively enough at the=20 Minneapolis meeting it seemed like it would be=20 more productive to express it in the form of a=20 fully written specification instead of a list of=20 comments. If you haven't read=20 draft-keyur-prefixlimit-orf-00 then please do=20 (it's short). If having read it you do think=20 that it's more complex, I'd love to discuss the=20 reasons. Of course, I would also like to hear=20 what other members of the WG think. We'd be happy to make reasonable changes to the=20 acknowledgement section if you'd like to=20 communicate what the problem is, either on or off=20 list. Respectfully, --John At 12:36 PM -0400 4/28/04, Susan Hares wrote: >John: > >Well this is amazing. Since you suggested the complexity... >Perhaps you changed your mind. > >We put the complex ORF policy in because you state >Cisco did not support dynamic configuration. >In simplifying this, I do not find people wanting to >go to an ORF policy.=A0 > >Sue > >PS - your acknowledgement section is problematic. > >-----Original Message----- >From: John G. Scudder [mailto:jgs@cisco.com] >Sent: Wednesday, April 28, 2004 11:19 AM >To: idr@ietf.org >Subject: [Idr] draft-keyur-prefixlimit-orf-00 > > >Folks, > >As others have noted, while the underlying goal of >draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the >actual mechanisms proposed are more complex than is necessary. > >We've written another draft which we think provides the needed >functionality with less complexity, along the lines of what I >suggested at the meeting in Minneapolis. In summary we introduce a >new ORF-type which carries a 32 bit prefix limit, and also use the >PERMIT/DENY flag to signal whether enforcement of the limit will be >done by dropping the session or not. The draft is a tad over four >pages plus six pages of IETF boilerplate. > >The draft has been submitted as an I-D. Until it's available in the >usual places, you can find it at >ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt > >Discussion of the draft would be welcome. > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 13:44:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02637 for ; Wed, 28 Apr 2004 13:44:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt6g-0002XG-Tb for idr-archive@ietf.org; Wed, 28 Apr 2004 13:44:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt5u-0002Tt-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 13:43:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIt54-0002Qh-00; Wed, 28 Apr 2004 13:42:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIssq-0007lq-6A; Wed, 28 Apr 2004 13:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIskU-0005Vf-7e for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:21: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 NAA00323 for ; Wed, 28 Apr 2004 13:21:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIskQ-0000XL-Vn for idr@ietf.org; Wed, 28 Apr 2004 13:21:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsjV-0000UP-00 for idr@ietf.org; Wed, 28 Apr 2004 13:20:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIsis-0000Pn-00 for idr@ietf.org; Wed, 28 Apr 2004 13:19:50 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E04A52D49FC for ; Wed, 28 Apr 2004 13:19:21 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 75888-01-30 for ; Wed, 28 Apr 2004 13:19:08 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 81F122D4869 for ; Wed, 28 Apr 2004 13:19:08 -0400 (EDT) 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: draft-chen-bgp-avoid-transition-01.txt Thread-Index: AcQtRCsdoWQqfWGLQSW/EtgbXqiGfgAAKEsA From: "Susan Hares" To: "Enke Chen" , Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] RE: draft-chen-bgp-avoid-transition-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, 28 Apr 2004 13:19:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Enke: Please drop me a note to indicate where the draft has been deployed and in what routers. Are there inter-operable implementations? Sue -----Original Message----- From: Enke Chen [mailto:enke@redback.com] Sent: Wednesday, April 28, 2004 1:13 PM To: yakov@juniper.net; Susan Hares Cc: idr@ietf.org Subject: draft-chen-bgp-avoid-transition-01.txt Hi, Yakov and Sue: I would like to request that the draft = be accepted as an IDR WG document. The draft was presented previosuly at = an IDR meeting. The algorithm described in the draft has been deployed for = several years. Thanks. -- Enke ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Avoid BGP Best Path Transition from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 =09 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.tx= t ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 13:44:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02674 for ; Wed, 28 Apr 2004 13:44:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsxP-0000UH-Jl for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:34:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHYpUi001868 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsoh-0006hZ-LI for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:25: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 NAA00910 for ; Wed, 28 Apr 2004 13:25:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsoe-0000xi-8r for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:25:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIso0-0000rH-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:25:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsmv-0000kw-00; Wed, 28 Apr 2004 13:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsWZ-0001jl-8N; Wed, 28 Apr 2004 13:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsQ7-0008P8-GT for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28716 for ; Wed, 28 Apr 2004 13:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsQ4-0006ra-HM for idr@ietf.org; Wed, 28 Apr 2004 13:00:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsPB-0006p2-00 for idr@ietf.org; Wed, 28 Apr 2004 12:59:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIsOh-0006mF-00 for idr@ietf.org; Wed, 28 Apr 2004 12:58:59 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7C0042D4A05 for ; Wed, 28 Apr 2004 12:58:30 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74394-01-73 for ; Wed, 28 Apr 2004 12:58:17 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E95D02D4877 for ; Wed, 28 Apr 2004 12:58:17 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Message-ID: Thread-Topic: [Idr] draft-keyur-prefixlimit-orf-00 Thread-Index: AcQtQPIUe5/VlB+ZRma6+cq5bG02PAAACVhw From: "Susan Hares" To: "John G. Scudder" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 12:58:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable John: Read document before I sent the message.=20 Complexity came in -01 came in allowing ORFs as well as the global limits. We set it=20 up as an option and worked out the coordination deals So, we'll just trying to allow both methods. Capabilities and Dynamic capabilities provide a simple way to determine the 3 prefix limits: warning, stop receiving and disconnect per peer. The support of dynamic allows re-negotiation easily on a connection basis.=20 ORFs is too heavy weighted for that simple focus.=20 If we are trying to travel light, ORFs are like adding a 2 ton weight to your baggage.=20 Sue -----Original Message----- From: John G. Scudder [mailto:jgs@cisco.com] Sent: Wednesday, April 28, 2004 12:50 PM To: Susan Hares Cc: idr@ietf.org Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Sue, Sorry you feel that way. As you might imagine, I=20 have a different perspective, which is that I=20 tried to suggest a way to simplify the=20 specification, but instead found the -01 version=20 to be more complex. Since I clearly didn't=20 communicate the idea effectively enough at the=20 Minneapolis meeting it seemed like it would be=20 more productive to express it in the form of a=20 fully written specification instead of a list of=20 comments. If you haven't read=20 draft-keyur-prefixlimit-orf-00 then please do=20 (it's short). If having read it you do think=20 that it's more complex, I'd love to discuss the=20 reasons. Of course, I would also like to hear=20 what other members of the WG think. We'd be happy to make reasonable changes to the=20 acknowledgement section if you'd like to=20 communicate what the problem is, either on or off=20 list. Respectfully, --John At 12:36 PM -0400 4/28/04, Susan Hares wrote: >John: > >Well this is amazing. Since you suggested the complexity... >Perhaps you changed your mind. > >We put the complex ORF policy in because you state >Cisco did not support dynamic configuration. >In simplifying this, I do not find people wanting to >go to an ORF policy.=A0 > >Sue > >PS - your acknowledgement section is problematic. > >-----Original Message----- >From: John G. Scudder [mailto:jgs@cisco.com] >Sent: Wednesday, April 28, 2004 11:19 AM >To: idr@ietf.org >Subject: [Idr] draft-keyur-prefixlimit-orf-00 > > >Folks, > >As others have noted, while the underlying goal of >draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the >actual mechanisms proposed are more complex than is necessary. > >We've written another draft which we think provides the needed >functionality with less complexity, along the lines of what I >suggested at the meeting in Minneapolis. In summary we introduce a >new ORF-type which carries a 32 bit prefix limit, and also use the >PERMIT/DENY flag to signal whether enforcement of the limit will be >done by dropping the session or not. The draft is a tad over four >pages plus six pages of IETF boilerplate. > >The draft has been submitted as an I-D. Until it's available in the >usual places, you can find it at >ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt > >Discussion of the draft would be welcome. > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 13:57:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03584 for ; Wed, 28 Apr 2004 13:57: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 1BIt99-0003Q1-6b for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:46:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHkxpV013141 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:46:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt21-0001g6-5L for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:39:37 -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 NAA02192 for ; Wed, 28 Apr 2004 13:39:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt1x-00027H-LE for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:39:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt0y-00023N-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:38:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIt0M-00020F-00; Wed, 28 Apr 2004 13:37:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIssj-0007kb-Ka; Wed, 28 Apr 2004 13:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsf9-00047t-6Z for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29890 for ; Wed, 28 Apr 2004 13:15:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsf5-00008l-VU for idr@ietf.org; Wed, 28 Apr 2004 13:15:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIseA-00001K-00 for idr@ietf.org; Wed, 28 Apr 2004 13:14:58 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BIscl-0007hT-00 for idr@ietf.org; Wed, 28 Apr 2004 13:13:32 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5508CA6EBA1; Wed, 28 Apr 2004 10:13:32 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09989-06; Wed, 28 Apr 2004 10:13:32 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 8A422A6EBA0; Wed, 28 Apr 2004 10:13:30 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id B1AB915D3C2; Wed, 28 Apr 2004 10:13:29 -0700 (PDT) To: yakov@juniper.net, skh@nexthop.com Cc: idr@ietf.org From: Enke Chen Message-Id: <20040428171329.B1AB915D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] draft-chen-bgp-avoid-transition-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, 28 Apr 2004 10:13:29 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Yakov and Sue: I would like to request that the draft be accepted as an IDR WG document. The draft was presented previosuly at an IDR meeting. The algorithm described in the draft has been deployed for several years. Thanks. -- Enke ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoid BGP Best Path Transition from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 14:03:13 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04283 for ; Wed, 28 Apr 2004 14:03:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItD0-0004Fo-JK for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:50:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHow9v016347 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 13:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt6m-0002kq-NQ for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02663 for ; Wed, 28 Apr 2004 13:44:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt6j-0002XY-9D for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:44:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt5v-0002U9-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 13:43:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIt54-0002Qh-00; Wed, 28 Apr 2004 13:42:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIssq-0007lq-6A; Wed, 28 Apr 2004 13:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIskU-0005Vf-7e for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:21: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 NAA00323 for ; Wed, 28 Apr 2004 13:21:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIskQ-0000XL-Vn for idr@ietf.org; Wed, 28 Apr 2004 13:21:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsjV-0000UP-00 for idr@ietf.org; Wed, 28 Apr 2004 13:20:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIsis-0000Pn-00 for idr@ietf.org; Wed, 28 Apr 2004 13:19:50 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E04A52D49FC for ; Wed, 28 Apr 2004 13:19:21 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 75888-01-30 for ; Wed, 28 Apr 2004 13:19:08 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 81F122D4869 for ; Wed, 28 Apr 2004 13:19:08 -0400 (EDT) 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: draft-chen-bgp-avoid-transition-01.txt Thread-Index: AcQtRCsdoWQqfWGLQSW/EtgbXqiGfgAAKEsA From: "Susan Hares" To: "Enke Chen" , Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] RE: draft-chen-bgp-avoid-transition-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, 28 Apr 2004 13:19:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Enke: Please drop me a note to indicate where the draft has been deployed and in what routers. Are there inter-operable implementations? Sue -----Original Message----- From: Enke Chen [mailto:enke@redback.com] Sent: Wednesday, April 28, 2004 1:13 PM To: yakov@juniper.net; Susan Hares Cc: idr@ietf.org Subject: draft-chen-bgp-avoid-transition-01.txt Hi, Yakov and Sue: I would like to request that the draft = be accepted as an IDR WG document. The draft was presented previosuly at = an IDR meeting. The algorithm described in the draft has been deployed for = several years. Thanks. -- Enke ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Avoid BGP Best Path Transition from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 =09 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.tx= t ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 18:15:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28328 for ; Wed, 28 Apr 2004 18:15:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxKy-0005AO-L6 for idr-archive@ietf.org; Wed, 28 Apr 2004 18:15:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxK0-00050W-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 18:14:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxJ4-0004um-00; Wed, 28 Apr 2004 18:13:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwxJ-0006x1-Nk; Wed, 28 Apr 2004 17:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwlD-0008I5-CI for idr@optimus.ietf.org; Wed, 28 Apr 2004 17:38: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 RAA24991 for ; Wed, 28 Apr 2004 17:38:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwl9-0001tm-Jq for idr@ietf.org; Wed, 28 Apr 2004 17:38:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwkH-0001q6-00 for idr@ietf.org; Wed, 28 Apr 2004 17:37:34 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1BIwjK-0001jX-00 for idr@ietf.org; Wed, 28 Apr 2004 17:36:34 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWW0056ZH0ZWT@firewall.mci.com> for idr@ietf.org; Wed, 28 Apr 2004 21:29:23 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWW00H01GZ2BG@pmismtp02.mcilink.com>; Wed, 28 Apr 2004 21:29:23 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWW00GDAH0DVT@pmismtp02.mcilink.com>; Wed, 28 Apr 2004 21:29:01 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] Soft-Notify as an IDR WG document In-reply-to: <200404281646.i3SGkEde024649@roque-bsd.juniper.net> To: "'Pedro Roque Marques'" Cc: idr@ietf.org, "'Yakov Rekhter'" Message-id: <004901c42d67$d2e12b70$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 17:29:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I am not sure if it was a complete misrepresentation of your argument. = You do mention in your mail that=20 >> Besides multisession is 10x easier to implement and deploy since it = can use existing state machines. As an operator we definitely do keep network management implications in = our mind while choosing any mechanism and I appreciate your concern there. = And the fact that adding BGP complexity is worrying some is a good sign.=20 Though whatever choice you make has tactical as well as strategic implications. BGP is becoming a generic protocol to transport not only routing but also service information. Now the question is whether to = control these information flows at a higher AFI/SAFI level or to split them = apart and tie them down to lower tcp session level? Definitely the operators = are familiar with managing BGP TCP sessions, but if you are too quick to = arrive at the latter alternative and discard the former one for lack of NMS functions you may run the risk of not assigning the right function to = the right component. I have no idea how the number of AFI/SAFI and their functions there-of are going to evolve in future, but if we start = bundling them together in subsets and tie the control mechanisms of each subset = to a tcp session, it has to be more conscious and well thought decision than = a quick tactical one depending on short-term merit. I will be interested in understanding how multisession BGP stacks up = with running completely separate BGP between the same end points. [I = understand that its not doable now, but just trying to gauge the merit] -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net]=20 Sent: Wednesday, April 28, 2004 12:46 PM To: Parantap Lahiri Cc: idr@ietf.org; 'Yakov Rekhter' Subject: RE: [Idr] Soft-Notify as an IDR WG document Parantap Lahiri writes: > Now, here is this thread, where a part of the same community is > suggesting that giving individual soft control to each AFI/SAFI pair > would make BGP protocol implementation more complicated than > necessary and we should push the complexity to the operator > world. That is fine and in some ways sane, but in most ways > confusing. This is a misrepresentation of the argument. The point is that you cannot achieve individual control for afi/safi without adding the necessary diagnostics and support for tools and management on the operator side. Not to mention understanding of how mecanisms work. The multisession draft is nicer alternative for several reasons including the fact that it fits into the current management framework and follows a model understood by all. The point is not wether to achieve a given end goal but to find the approach that gets us there with less pain. and which can be built incrementally.=20 As an operator i would expect you to be supportive of the need to consider the network management implications before picking a solution. Pedro.=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 18:34:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00032 for ; Wed, 28 Apr 2004 18:34: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 1BIxYD-00016L-Ak for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 18:29:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMT9BY004234 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 18:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxL7-0004W8-2u for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:15:37 -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 SAA28359 for ; Wed, 28 Apr 2004 18:15:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxL2-0005B3-Vh for idr-web-archive@ietf.org; Wed, 28 Apr 2004 18:15:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxK2-00050p-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 18:14:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxJ4-0004um-00; Wed, 28 Apr 2004 18:13:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwxJ-0006x1-Nk; Wed, 28 Apr 2004 17:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwlD-0008I5-CI for idr@optimus.ietf.org; Wed, 28 Apr 2004 17:38: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 RAA24991 for ; Wed, 28 Apr 2004 17:38:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwl9-0001tm-Jq for idr@ietf.org; Wed, 28 Apr 2004 17:38:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwkH-0001q6-00 for idr@ietf.org; Wed, 28 Apr 2004 17:37:34 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1BIwjK-0001jX-00 for idr@ietf.org; Wed, 28 Apr 2004 17:36:34 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWW0056ZH0ZWT@firewall.mci.com> for idr@ietf.org; Wed, 28 Apr 2004 21:29:23 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWW00H01GZ2BG@pmismtp02.mcilink.com>; Wed, 28 Apr 2004 21:29:23 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWW00GDAH0DVT@pmismtp02.mcilink.com>; Wed, 28 Apr 2004 21:29:01 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] Soft-Notify as an IDR WG document In-reply-to: <200404281646.i3SGkEde024649@roque-bsd.juniper.net> To: "'Pedro Roque Marques'" Cc: idr@ietf.org, "'Yakov Rekhter'" Message-id: <004901c42d67$d2e12b70$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 17:29:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I am not sure if it was a complete misrepresentation of your argument. = You do mention in your mail that=20 >> Besides multisession is 10x easier to implement and deploy since it = can use existing state machines. As an operator we definitely do keep network management implications in = our mind while choosing any mechanism and I appreciate your concern there. = And the fact that adding BGP complexity is worrying some is a good sign.=20 Though whatever choice you make has tactical as well as strategic implications. BGP is becoming a generic protocol to transport not only routing but also service information. Now the question is whether to = control these information flows at a higher AFI/SAFI level or to split them = apart and tie them down to lower tcp session level? Definitely the operators = are familiar with managing BGP TCP sessions, but if you are too quick to = arrive at the latter alternative and discard the former one for lack of NMS functions you may run the risk of not assigning the right function to = the right component. I have no idea how the number of AFI/SAFI and their functions there-of are going to evolve in future, but if we start = bundling them together in subsets and tie the control mechanisms of each subset = to a tcp session, it has to be more conscious and well thought decision than = a quick tactical one depending on short-term merit. I will be interested in understanding how multisession BGP stacks up = with running completely separate BGP between the same end points. [I = understand that its not doable now, but just trying to gauge the merit] -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net]=20 Sent: Wednesday, April 28, 2004 12:46 PM To: Parantap Lahiri Cc: idr@ietf.org; 'Yakov Rekhter' Subject: RE: [Idr] Soft-Notify as an IDR WG document Parantap Lahiri writes: > Now, here is this thread, where a part of the same community is > suggesting that giving individual soft control to each AFI/SAFI pair > would make BGP protocol implementation more complicated than > necessary and we should push the complexity to the operator > world. That is fine and in some ways sane, but in most ways > confusing. This is a misrepresentation of the argument. The point is that you cannot achieve individual control for afi/safi without adding the necessary diagnostics and support for tools and management on the operator side. Not to mention understanding of how mecanisms work. The multisession draft is nicer alternative for several reasons including the fact that it fits into the current management framework and follows a model understood by all. The point is not wether to achieve a given end goal but to find the approach that gets us there with less pain. and which can be built incrementally.=20 As an operator i would expect you to be supportive of the need to consider the network management implications before picking a solution. Pedro.=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 19:06:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01832 for ; Wed, 28 Apr 2004 19:06:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIy8W-0001OQ-OM for idr-archive@ietf.org; Wed, 28 Apr 2004 19:06:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIy7X-0001Je-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 19:05:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIy79-0001Fj-00; Wed, 28 Apr 2004 19:05:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxyC-0000Xc-VS; Wed, 28 Apr 2004 18:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxmA-0006H6-4l for idr@optimus.ietf.org; Wed, 28 Apr 2004 18:43: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 SAA00596 for ; Wed, 28 Apr 2004 18:43:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxm5-0007Nv-LZ for idr@ietf.org; Wed, 28 Apr 2004 18:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxl9-0007Jq-00 for idr@ietf.org; Wed, 28 Apr 2004 18:42:31 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIxkQ-0007C5-00 for idr@ietf.org; Wed, 28 Apr 2004 18:41:46 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3SMfH5O025163; Wed, 28 Apr 2004 15:41:17 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3SMfHhx025160; Wed, 28 Apr 2004 15:41:17 -0700 (PDT) Message-Id: <200404282241.i3SMfHhx025160@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: yakov@juniper.net, skh@nexthop.com, idr@ietf.org Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 28 Apr 2004 15:41:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Enke Chen writes: > Hi, Yakov and Sue: I would like to request that the draft > be accepted as an IDR WG > document. The draft was presented previosuly at an IDR meeting. The > algorithm described in the draft has been deployed for several > years. my turn to cheer: i believe this should be a wg document. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Apr 28 19:11:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02068 for ; Wed, 28 Apr 2004 19:11:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyDY-0001pU-7w for idr-archive@ietf.org; Wed, 28 Apr 2004 19:11:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyCW-0001jR-00 for idr-archive@ietf.org; Wed, 28 Apr 2004 19:10:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIyBr-0001e5-00; Wed, 28 Apr 2004 19:10:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy5y-0003bo-AS; Wed, 28 Apr 2004 19:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxxq-0000Vt-US for idr@optimus.ietf.org; Wed, 28 Apr 2004 18:55:38 -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 SAA01111 for ; Wed, 28 Apr 2004 18:55:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxxm-0000Rr-Gb for idr@ietf.org; Wed, 28 Apr 2004 18:55:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxwq-0000MV-00 for idr@ietf.org; Wed, 28 Apr 2004 18:54:37 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIxw1-0000EP-00 for idr@ietf.org; Wed, 28 Apr 2004 18:53:45 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SMrDW9028605 for ; Wed, 28 Apr 2004 15:53:14 -0700 (PDT) Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3SJcXjO013688; Wed, 28 Apr 2004 12:38:33 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id MAA11077; Wed, 28 Apr 2004 12:38:32 -0700 In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/mixed; boundary=Apple-Mail-4--352788604 Message-Id: Cc: yakov@juniper.net, skh@nexthop.com From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen , idr@ietf.org X-Mailer: Apple Mail (2.613) 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, 28 Apr 2004 14:38:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-4--352788604 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Apr 28, 2004, at 12:13 PM, Enke Chen wrote: > Hi, Yakov and Sue: > > I would like to request that the draft > > be accepted as an IDR WG document. The draft was presented previosuly > at an > IDR meeting. The algorithm described in the draft has been deployed > for several > years. > > Thanks. -- Enke > > ------- Forwarded Message > > Message-Id: <200401201504.KAA02287@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt > Date: Tue, 20 Jan 2004 10:04:35 -0500 > > - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Avoid BGP Best Path Transition from One External to Another > Author(s) : E. Chen, S. Sangli > Filename : draft-chen-bgp-avoid-transition-01.txt > Pages : 5 > Date : 2004-1-19 > > In this document we propose an algorithm that would help improve the > overall network stability by avoiding BGP best path transition from > one external to another (under certain conditions) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition > -01.txt > > > ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > Hi Enke, Attached is an email I sent to IDR that discusses some issues around your draft. I don't think I have seen a reply. I will add now that since that note I've discussed and thought a bit more about your argument in 5.2, and I think it is quite clear (and is indeed the received opinion nowadays) that the essential ingredient in these route-oscillation problems is the interaction of Route Reflectors and IGP costs. Using sufficiently high IGP costs between clusters will suffice to stop the churn both in your scenario and in other scenarios that don't involve router-id. Indeed, in your scenario if by chance the times of arrival correspond in the same order to that determined by the router-ids the churn is not avoided by your algorithm either (the proof is tedious, but intuitively: start the scenario with the same ranking of tie-breakers, just use time-of-arrival instead of router-id; then realize that this order gets preserved as the oscillation proceeds because the repeatedly advertised-and-withdrawn route will always be "newest" and correspond to the largest router id in the original scenario.) But as I say in the attached, my argument is really with section 5.2, not with your overall proposal. There are implementations that provide a knob to do just what you are documenting and I agree that the BGP spec should provide for this option. Best regards, Tom Barron --Apple-Mail-4--352788604 Content-Type: text/plain; x-unix-mode=0600; name="reduce-route-oscillation-discussion.txt" Content-Disposition: attachment; filename=reduce-route-oscillation-discussion.txt Content-Transfer-Encoding: 7bit From exim@www1.ietf.org Wed Apr 28 19:29:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03017 for ; Wed, 28 Apr 2004 19:29: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 1BIyH2-0006gP-Ub for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 19:15:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNFSPY025681 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 19:15:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy8c-0004h1-Jk for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:06: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 TAA01858 for ; Wed, 28 Apr 2004 19:06:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIy8Y-0001Oa-2Q for idr-web-archive@ietf.org; Wed, 28 Apr 2004 19:06:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIy7Y-0001Jt-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 19:05:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIy79-0001Fj-00; Wed, 28 Apr 2004 19:05:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxyC-0000Xc-VS; Wed, 28 Apr 2004 18:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxmA-0006H6-4l for idr@optimus.ietf.org; Wed, 28 Apr 2004 18:43: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 SAA00596 for ; Wed, 28 Apr 2004 18:43:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxm5-0007Nv-LZ for idr@ietf.org; Wed, 28 Apr 2004 18:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxl9-0007Jq-00 for idr@ietf.org; Wed, 28 Apr 2004 18:42:31 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIxkQ-0007C5-00 for idr@ietf.org; Wed, 28 Apr 2004 18:41:46 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3SMfH5O025163; Wed, 28 Apr 2004 15:41:17 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3SMfHhx025160; Wed, 28 Apr 2004 15:41:17 -0700 (PDT) Message-Id: <200404282241.i3SMfHhx025160@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: yakov@juniper.net, skh@nexthop.com, idr@ietf.org Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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, 28 Apr 2004 15:41:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Enke Chen writes: > Hi, Yakov and Sue: I would like to request that the draft > be accepted as an IDR WG > document. The draft was presented previosuly at an IDR meeting. The > algorithm described in the draft has been deployed for several > years. my turn to cheer: i believe this should be a wg document. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Apr 28 19:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03266 for ; Wed, 28 Apr 2004 19:30: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 1BIyTR-0001iA-FJ for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 19:28:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNSHE1006573 for idr-archive@odin.ietf.org; Wed, 28 Apr 2004 19:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyDe-0006Mz-5s for idr-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02094 for ; Wed, 28 Apr 2004 19:11:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyDZ-0001pf-KZ for idr-web-archive@ietf.org; Wed, 28 Apr 2004 19:11:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyCY-0001jg-00 for idr-web-archive@ietf.org; Wed, 28 Apr 2004 19:10:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIyBr-0001e5-00; Wed, 28 Apr 2004 19:10:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy5y-0003bo-AS; Wed, 28 Apr 2004 19:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxxq-0000Vt-US for idr@optimus.ietf.org; Wed, 28 Apr 2004 18:55:38 -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 SAA01111 for ; Wed, 28 Apr 2004 18:55:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxxm-0000Rr-Gb for idr@ietf.org; Wed, 28 Apr 2004 18:55:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxwq-0000MV-00 for idr@ietf.org; Wed, 28 Apr 2004 18:54:37 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIxw1-0000EP-00 for idr@ietf.org; Wed, 28 Apr 2004 18:53:45 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SMrDW9028605 for ; Wed, 28 Apr 2004 15:53:14 -0700 (PDT) Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3SJcXjO013688; Wed, 28 Apr 2004 12:38:33 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id MAA11077; Wed, 28 Apr 2004 12:38:32 -0700 In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/mixed; boundary=Apple-Mail-4--352788604 Message-Id: Cc: yakov@juniper.net, skh@nexthop.com From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen , idr@ietf.org X-Mailer: Apple Mail (2.613) 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, 28 Apr 2004 14:38:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-4--352788604 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Apr 28, 2004, at 12:13 PM, Enke Chen wrote: > Hi, Yakov and Sue: > > I would like to request that the draft > > be accepted as an IDR WG document. The draft was presented previosuly > at an > IDR meeting. The algorithm described in the draft has been deployed > for several > years. > > Thanks. -- Enke > > ------- Forwarded Message > > Message-Id: <200401201504.KAA02287@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt > Date: Tue, 20 Jan 2004 10:04:35 -0500 > > - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Avoid BGP Best Path Transition from One External to Another > Author(s) : E. Chen, S. Sangli > Filename : draft-chen-bgp-avoid-transition-01.txt > Pages : 5 > Date : 2004-1-19 > > In this document we propose an algorithm that would help improve the > overall network stability by avoiding BGP best path transition from > one external to another (under certain conditions) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition > -01.txt > > > ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > Hi Enke, Attached is an email I sent to IDR that discusses some issues around your draft. I don't think I have seen a reply. I will add now that since that note I've discussed and thought a bit more about your argument in 5.2, and I think it is quite clear (and is indeed the received opinion nowadays) that the essential ingredient in these route-oscillation problems is the interaction of Route Reflectors and IGP costs. Using sufficiently high IGP costs between clusters will suffice to stop the churn both in your scenario and in other scenarios that don't involve router-id. Indeed, in your scenario if by chance the times of arrival correspond in the same order to that determined by the router-ids the churn is not avoided by your algorithm either (the proof is tedious, but intuitively: start the scenario with the same ranking of tie-breakers, just use time-of-arrival instead of router-id; then realize that this order gets preserved as the oscillation proceeds because the repeatedly advertised-and-withdrawn route will always be "newest" and correspond to the largest router id in the original scenario.) But as I say in the attached, my argument is really with section 5.2, not with your overall proposal. There are implementations that provide a knob to do just what you are documenting and I agree that the BGP spec should provide for this option. Best regards, Tom Barron --Apple-Mail-4--352788604 Content-Type: text/plain; x-unix-mode=0600; name="reduce-route-oscillation-discussion.txt" Content-Disposition: attachment; filename=reduce-route-oscillation-discussion.txt Content-Transfer-Encoding: 7bit From idr-admin@ietf.org Thu Apr 29 11:15:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08550 for ; Thu, 29 Apr 2004 11:15:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDGK-0003cQ-AC for idr-archive@ietf.org; Thu, 29 Apr 2004 11:15:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDFC-0003Lc-00 for idr-archive@ietf.org; Thu, 29 Apr 2004 11:14:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDEU-00034t-00; Thu, 29 Apr 2004 11:13:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJD34-000051-4O; Thu, 29 Apr 2004 11:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCo3-0004sK-Vl for idr@optimus.ietf.org; Thu, 29 Apr 2004 10:46: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 KAA06569 for ; Thu, 29 Apr 2004 10:46:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCns-0003Bn-G6 for idr@ietf.org; Thu, 29 Apr 2004 10:46:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCmz-0002w8-00 for idr@ietf.org; Thu, 29 Apr 2004 10:45:25 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1BJCmQ-0002g9-00 for idr@ietf.org; Thu, 29 Apr 2004 10:44:50 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TEiIF11189; Thu, 29 Apr 2004 09:44:19 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J4L1A4SX; Thu, 29 Apr 2004 07:44:19 -0700 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN02N1D; Thu, 29 Apr 2004 10:44:17 -0400 Message-ID: <409114C0.4080801@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document References: <200404151359.i3FDxsJ92103@merlot.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: Thu, 29 Apr 2004 10:44:16 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit In response to some of the comments made on this draft in the WG, we have made some changes to the 01 version of the draft. The following is the link to the new draft which is based of 00 version as suggested by some. http://ndzh.com/idr/Drafts/draft-chavali-bgp-prefixlimit-02.txt This is has been submitted as an internet draft today. Please forward your your comments to the list. Thanks srikanth chavali _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 29 11:41:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09869 for ; Thu, 29 Apr 2004 11:41: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 1BJDTy-0007oE-Vp for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 11:29:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFToNa030019 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 11:29:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDGQ-0004aT-RF for idr-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:15: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 LAA08577 for ; Thu, 29 Apr 2004 11:15:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDGM-0003ci-NT for idr-web-archive@ietf.org; Thu, 29 Apr 2004 11:15:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDFE-0003Lq-00 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 11:14:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDEU-00034t-00; Thu, 29 Apr 2004 11:13:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJD34-000051-4O; Thu, 29 Apr 2004 11:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCo3-0004sK-Vl for idr@optimus.ietf.org; Thu, 29 Apr 2004 10:46: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 KAA06569 for ; Thu, 29 Apr 2004 10:46:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCns-0003Bn-G6 for idr@ietf.org; Thu, 29 Apr 2004 10:46:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCmz-0002w8-00 for idr@ietf.org; Thu, 29 Apr 2004 10:45:25 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1BJCmQ-0002g9-00 for idr@ietf.org; Thu, 29 Apr 2004 10:44:50 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TEiIF11189; Thu, 29 Apr 2004 09:44:19 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J4L1A4SX; Thu, 29 Apr 2004 07:44:19 -0700 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN02N1D; Thu, 29 Apr 2004 10:44:17 -0400 Message-ID: <409114C0.4080801@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document References: <200404151359.i3FDxsJ92103@merlot.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: Thu, 29 Apr 2004 10:44:16 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In response to some of the comments made on this draft in the WG, we have made some changes to the 01 version of the draft. The following is the link to the new draft which is based of 00 version as suggested by some. http://ndzh.com/idr/Drafts/draft-chavali-bgp-prefixlimit-02.txt This is has been submitted as an internet draft today. Please forward your your comments to the list. Thanks srikanth chavali _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 29 12:08:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11228 for ; Thu, 29 Apr 2004 12:08:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJE59-00025f-KR for idr-archive@ietf.org; Thu, 29 Apr 2004 12:08:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJE49-0001oe-00 for idr-archive@ietf.org; Thu, 29 Apr 2004 12:07:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJE3B-0001Xs-00; Thu, 29 Apr 2004 12:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDqU-0005xm-BE; Thu, 29 Apr 2004 11:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDUT-00084w-Gv for idr@optimus.ietf.org; Thu, 29 Apr 2004 11:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09187 for ; Thu, 29 Apr 2004 11:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDUP-0007T2-7v for idr@ietf.org; Thu, 29 Apr 2004 11:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDTV-0007Ds-00 for idr@ietf.org; Thu, 29 Apr 2004 11:29:22 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJDSi-0006jU-00 for idr@ietf.org; Thu, 29 Apr 2004 11:28:32 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TFMhJ31771; Thu, 29 Apr 2004 18:22:43 +0300 From: Pekka Savola To: Parantap Lahiri cc: "'Gargi Nalawade'" , "'Pedro Roque Marques'" , , "'Yakov Rekhter'" Subject: RE: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <002601c42d39$22a08ef0$a3922799@mcilink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 18:22:43 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 28 Apr 2004, Parantap Lahiri wrote: > If the community has already made its mind that BGP is going to carry most > of the services, the vendor community has accepted to undertake that > incremental complexity and the operators have accepted to live with the > risk, then resisting this draft from going to WG, is a mixed signal. If > everyone HAS to live with multiple AFI/SAFI in the same session, they might > as well get their control and not think about how many sets of sessions they > should run in their infrastructure. Why would anyone want have to live with multiple AFI/SAFI in the same session if (s)he could set them up as separate sessions? It seems that soft-notify accomplishes a subset of goals which multisession (and the like accomplish), but with a lot of additional issues. The implementation or deployment complexity is probably roughly equal. So, this makes me wonder why soft-notify should go forward here at all? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 29 12:37:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12744 for ; Thu, 29 Apr 2004 12:37:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEXN-0002ZE-J1 for idr-archive@ietf.org; Thu, 29 Apr 2004 12:37:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEWM-0002Dg-00 for idr-archive@ietf.org; Thu, 29 Apr 2004 12:36:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJEVJ-0001qH-00; Thu, 29 Apr 2004 12:35:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJEVO-0004An-8N; Thu, 29 Apr 2004 12:35:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEEc-00068x-HE; Thu, 29 Apr 2004 12:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDrs-0006Kh-2o for idr@optimus.ietf.org; Thu, 29 Apr 2004 11:54: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 LAA10574 for ; Thu, 29 Apr 2004 11:54:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDrn-0006DP-FC for idr@ietf.org; Thu, 29 Apr 2004 11:54:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDqq-0005x8-00 for idr@ietf.org; Thu, 29 Apr 2004 11:53:29 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJDqF-0005fP-00 for idr@ietf.org; Thu, 29 Apr 2004 11:52:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TFqEv32267; Thu, 29 Apr 2004 18:52:14 +0300 From: Pekka Savola To: Andrew Lange cc: Pedro Roque Marques , Yakov Rekhter , Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <7663189.1082986622@[192.168.5.191]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 18:52:14 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 26 Apr 2004, Andrew Lange wrote: > > Why do we need this in the first place? To "standardize" commonly > > used communities? To give the users more tools to mess up their > > routing, or to allow the users to make the ISP's policy more complex? > > Here is some additional text for the introduction which, I hope, will > answer your questions. > > There is a clear demand by BGP-savvy customers to have enhanced control > over their route announcements. Today this demand is addressed by custom, > complex and difficult to manage community policies. There is no > consistency across providers, except for the NO_EXPORT well known community > specified in RFC1997. There are more well-known communities for common > policies specified in this document to help provide commonality and ease of > maintenance. The current route policies required to provide enhanced BGP > services are very cumbersome. The larger space provided in flexible > communities, and the introduction of neighbor classes significantly ease > the implementation and maintenance burdens for service providers. > > Service providers also often tag their data based on where and from whom > they learned it (peer, customer, geographic origin). The flexible > community, and the neighbor class application especially, make both > assigning inbound communities and matching on outbound peers significantly > easier and less error prone. > > In addition, community values today are simply too small and too rigidly > defined to allow for the growth of the Internet. For example, encoding > IPv6 address and an action to take on them is simply impossible. This is clearer. However, there are still many things I find disturbing, based on the quick glance: - operator losing the control of the network. For us, the #1 thing in the network is being able to control the traffic flows etc. as we see fit except with the tools we give to the customers. So, this would seem to call for a statement that acting upon these communities should be disabled unless explicitly enabled. - IPv4/IPv6 addresses: these are very poor keys for communities and probably should not be included -- or is there a specific usage case for them? If there are needed, could these be implemented as a form of extended communities then? - usability for the customer: these are only applicable to the customer if the customer has already negotiated with the ISP that the ISP supports these communities, and has marked each and all the BGP sessions it has accordingly ("peer", "upstream", "transit", etc.); they aren't useful otherwise. This seems like a rather big leap to me. So what these are is a replacement for those ISPs who already community-based schemes to something "standardized". It doesn't help much (except a little with set-up complexity) with other ISPs, so it isn't a silver bullet. - similar to IPv4/IPv6 address applicability, the applicability of VPN communities seems a bit fuzzy. In addition to those the bandwidth community seems particularly unnecessary. - this appears to be confusing: The Flexible Community attribute MUST NOT be used to modify the BGP best path selection algorithm in a way that leads to forwarding loops. ==> does this allow that to happen? Do we want to specify anything that would lead to that? On the other hand, if we allow flexibility, the customer always has a possibility to shoot himself in the foot, and the protocol should not prevent that? (btw, the refs need to be split to normative/informative, and an IPR statement needs to be added.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 29 12:42:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13222 for ; Thu, 29 Apr 2004 12:42: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 1BJETO-0002x3-8X for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGXIqu011341 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJE5F-0002EC-OJ for idr-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:08:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11254 for ; Thu, 29 Apr 2004 12:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJE5B-00025p-5j for idr-web-archive@ietf.org; Thu, 29 Apr 2004 12:08:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJE4B-0001os-00 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 12:07:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJE3B-0001Xs-00; Thu, 29 Apr 2004 12:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDqU-0005xm-BE; Thu, 29 Apr 2004 11:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDUT-00084w-Gv for idr@optimus.ietf.org; Thu, 29 Apr 2004 11:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09187 for ; Thu, 29 Apr 2004 11:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDUP-0007T2-7v for idr@ietf.org; Thu, 29 Apr 2004 11:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDTV-0007Ds-00 for idr@ietf.org; Thu, 29 Apr 2004 11:29:22 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJDSi-0006jU-00 for idr@ietf.org; Thu, 29 Apr 2004 11:28:32 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TFMhJ31771; Thu, 29 Apr 2004 18:22:43 +0300 From: Pekka Savola To: Parantap Lahiri cc: "'Gargi Nalawade'" , "'Pedro Roque Marques'" , , "'Yakov Rekhter'" Subject: RE: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <002601c42d39$22a08ef0$a3922799@mcilink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 18:22:43 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 28 Apr 2004, Parantap Lahiri wrote: > If the community has already made its mind that BGP is going to carry most > of the services, the vendor community has accepted to undertake that > incremental complexity and the operators have accepted to live with the > risk, then resisting this draft from going to WG, is a mixed signal. If > everyone HAS to live with multiple AFI/SAFI in the same session, they might > as well get their control and not think about how many sets of sessions they > should run in their infrastructure. Why would anyone want have to live with multiple AFI/SAFI in the same session if (s)he could set them up as separate sessions? It seems that soft-notify accomplishes a subset of goals which multisession (and the like accomplish), but with a lot of additional issues. The implementation or deployment complexity is probably roughly equal. So, this makes me wonder why soft-notify should go forward here at all? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 29 12:49:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13487 for ; Thu, 29 Apr 2004 12:49: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 1BJEgD-0007ao-1k for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 12:46:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGkWTD029171 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 12:46:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEXT-0004hB-TI for idr-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:37: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 MAA12782 for ; Thu, 29 Apr 2004 12:37:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEXP-0002ZQ-21 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 12:37:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEWO-0002Du-00 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 12:36:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJEVJ-0001qH-00; Thu, 29 Apr 2004 12:35:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJEVO-0004An-8N; Thu, 29 Apr 2004 12:35:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEEc-00068x-HE; Thu, 29 Apr 2004 12:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDrs-0006Kh-2o for idr@optimus.ietf.org; Thu, 29 Apr 2004 11:54: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 LAA10574 for ; Thu, 29 Apr 2004 11:54:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDrn-0006DP-FC for idr@ietf.org; Thu, 29 Apr 2004 11:54:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDqq-0005x8-00 for idr@ietf.org; Thu, 29 Apr 2004 11:53:29 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJDqF-0005fP-00 for idr@ietf.org; Thu, 29 Apr 2004 11:52:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TFqEv32267; Thu, 29 Apr 2004 18:52:14 +0300 From: Pekka Savola To: Andrew Lange cc: Pedro Roque Marques , Yakov Rekhter , Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <7663189.1082986622@[192.168.5.191]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 18:52:14 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 26 Apr 2004, Andrew Lange wrote: > > Why do we need this in the first place? To "standardize" commonly > > used communities? To give the users more tools to mess up their > > routing, or to allow the users to make the ISP's policy more complex? > > Here is some additional text for the introduction which, I hope, will > answer your questions. > > There is a clear demand by BGP-savvy customers to have enhanced control > over their route announcements. Today this demand is addressed by custom, > complex and difficult to manage community policies. There is no > consistency across providers, except for the NO_EXPORT well known community > specified in RFC1997. There are more well-known communities for common > policies specified in this document to help provide commonality and ease of > maintenance. The current route policies required to provide enhanced BGP > services are very cumbersome. The larger space provided in flexible > communities, and the introduction of neighbor classes significantly ease > the implementation and maintenance burdens for service providers. > > Service providers also often tag their data based on where and from whom > they learned it (peer, customer, geographic origin). The flexible > community, and the neighbor class application especially, make both > assigning inbound communities and matching on outbound peers significantly > easier and less error prone. > > In addition, community values today are simply too small and too rigidly > defined to allow for the growth of the Internet. For example, encoding > IPv6 address and an action to take on them is simply impossible. This is clearer. However, there are still many things I find disturbing, based on the quick glance: - operator losing the control of the network. For us, the #1 thing in the network is being able to control the traffic flows etc. as we see fit except with the tools we give to the customers. So, this would seem to call for a statement that acting upon these communities should be disabled unless explicitly enabled. - IPv4/IPv6 addresses: these are very poor keys for communities and probably should not be included -- or is there a specific usage case for them? If there are needed, could these be implemented as a form of extended communities then? - usability for the customer: these are only applicable to the customer if the customer has already negotiated with the ISP that the ISP supports these communities, and has marked each and all the BGP sessions it has accordingly ("peer", "upstream", "transit", etc.); they aren't useful otherwise. This seems like a rather big leap to me. So what these are is a replacement for those ISPs who already community-based schemes to something "standardized". It doesn't help much (except a little with set-up complexity) with other ISPs, so it isn't a silver bullet. - similar to IPv4/IPv6 address applicability, the applicability of VPN communities seems a bit fuzzy. In addition to those the bandwidth community seems particularly unnecessary. - this appears to be confusing: The Flexible Community attribute MUST NOT be used to modify the BGP best path selection algorithm in a way that leads to forwarding loops. ==> does this allow that to happen? Do we want to specify anything that would lead to that? On the other hand, if we allow flexibility, the customer always has a possibility to shoot himself in the foot, and the protocol should not prevent that? (btw, the refs need to be split to normative/informative, and an IPR statement needs to be added.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 29 13:42:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15765 for ; Thu, 29 Apr 2004 13:42:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFYE-0004Wt-29 for idr-archive@ietf.org; Thu, 29 Apr 2004 13:42:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFXF-0004Dj-00 for idr-archive@ietf.org; Thu, 29 Apr 2004 13:41:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJFWN-0003v8-00; Thu, 29 Apr 2004 13:40:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFFE-0006lz-Jo; Thu, 29 Apr 2004 13:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEXW-0004hp-3A for idr@optimus.ietf.org; Thu, 29 Apr 2004 12:37: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 MAA12795 for ; Thu, 29 Apr 2004 12:37:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEXR-0002Zk-6V for idr@ietf.org; Thu, 29 Apr 2004 12:37:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEWa-0002FP-00 for idr@ietf.org; Thu, 29 Apr 2004 12:36:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJEVY-0001bN-00 for idr@ietf.org; Thu, 29 Apr 2004 12:35:32 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TGZ0000473; Thu, 29 Apr 2004 19:35:00 +0300 From: Pekka Savola To: Yakov Rekhter cc: Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: <200404201353.i3KDr1J39724@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 19:35:00 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > 2) The definition of active route is bad. This fails in the > > > situation where you need to export loopbacks/point-to-points to > > > eBGP, but you have them in youro IGP. The specification does not > > > consider them active (not used for forwarding), and they aren't > > > exported. > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > obviously this is no problem. Gargi Nalawade promised to submit > > > text, but hasn't, and I think Yakov said something about being > > > willing to incorporate that, but obviously hasn't. > > > > > > This was discussed at idr thread: > > > > > issue 11.2: active route, again > > > > > Otherwise, I think this was operationally good. > > > > Sue, Yakov, please check if the ball was dropped re this one. > > First of all, the consensus of the WG (as documented in > draft-ietf-idr-bgp-issues) is to have the following text: > > In the context of this document we assume that a BGP speaker > advertises to its peers only those routes that it itself uses (in > this context a BGP speaker is said to "use" a BGP route if it is the > most preferred BGP route and is used in forwarding). All other cases > are outside the scope of this document. > > While this text does not cover the case described by Pekka, it does > not preclude it either - handling the case described by Pekka > is just outside the scope of the spec. > > With this in mind I suggest that the case described by Pekka > should be covered in a separate Internet Draft. I think this is operationally a rather common (or even very common) scenario, and it would seem very disadvantageous not to tackle it in this specification. Further, there's major deployment of it (maybe even multi-vendor -- probably) so there is considerable proof that it works. It should be the default behaviour of BGP as that's which makes the most sense, operationally. "BGP route is ... used by forwarding" does not sufficiently cover the fact that people do use IGPs and there's often overlap with IGP and BGP :). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 29 13:51:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16838 for ; Thu, 29 Apr 2004 13:51: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 1BJFeE-0006Fx-5T for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 13:48:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3THmYXG024049 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 13:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFYL-0002zp-5r for idr-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 13:42:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15795 for ; Thu, 29 Apr 2004 13:42:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFYF-0004X4-Oi for idr-web-archive@ietf.org; Thu, 29 Apr 2004 13:42:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFXG-0004Dx-00 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 13:41:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJFWN-0003v8-00; Thu, 29 Apr 2004 13:40:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFFE-0006lz-Jo; Thu, 29 Apr 2004 13:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEXW-0004hp-3A for idr@optimus.ietf.org; Thu, 29 Apr 2004 12:37: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 MAA12795 for ; Thu, 29 Apr 2004 12:37:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEXR-0002Zk-6V for idr@ietf.org; Thu, 29 Apr 2004 12:37:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEWa-0002FP-00 for idr@ietf.org; Thu, 29 Apr 2004 12:36:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJEVY-0001bN-00 for idr@ietf.org; Thu, 29 Apr 2004 12:35:32 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TGZ0000473; Thu, 29 Apr 2004 19:35:00 +0300 From: Pekka Savola To: Yakov Rekhter cc: Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: <200404201353.i3KDr1J39724@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 19:35:00 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > 2) The definition of active route is bad. This fails in the > > > situation where you need to export loopbacks/point-to-points to > > > eBGP, but you have them in youro IGP. The specification does not > > > consider them active (not used for forwarding), and they aren't > > > exported. > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > obviously this is no problem. Gargi Nalawade promised to submit > > > text, but hasn't, and I think Yakov said something about being > > > willing to incorporate that, but obviously hasn't. > > > > > > This was discussed at idr thread: > > > > > issue 11.2: active route, again > > > > > Otherwise, I think this was operationally good. > > > > Sue, Yakov, please check if the ball was dropped re this one. > > First of all, the consensus of the WG (as documented in > draft-ietf-idr-bgp-issues) is to have the following text: > > In the context of this document we assume that a BGP speaker > advertises to its peers only those routes that it itself uses (in > this context a BGP speaker is said to "use" a BGP route if it is the > most preferred BGP route and is used in forwarding). All other cases > are outside the scope of this document. > > While this text does not cover the case described by Pekka, it does > not preclude it either - handling the case described by Pekka > is just outside the scope of the spec. > > With this in mind I suggest that the case described by Pekka > should be covered in a separate Internet Draft. I think this is operationally a rather common (or even very common) scenario, and it would seem very disadvantageous not to tackle it in this specification. Further, there's major deployment of it (maybe even multi-vendor -- probably) so there is considerable proof that it works. It should be the default behaviour of BGP as that's which makes the most sense, operationally. "BGP route is ... used by forwarding" does not sufficiently cover the fact that people do use IGPs and there's often overlap with IGP and BGP :). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 29 15:46:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24137 for ; Thu, 29 Apr 2004 15:46:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHUO-0005ua-SK for idr-archive@ietf.org; Thu, 29 Apr 2004 15:46:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHTM-0005ql-00 for idr-archive@ietf.org; Thu, 29 Apr 2004 15:45:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHSn-0005nU-00; Thu, 29 Apr 2004 15:44:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHDD-0006pu-BQ; Thu, 29 Apr 2004 15:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH3N-0001pm-In for idr@optimus.ietf.org; Thu, 29 Apr 2004 15:18:37 -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 PAA21769 for ; Thu, 29 Apr 2004 15:18:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH3H-0003kb-0v for idr@ietf.org; Thu, 29 Apr 2004 15:18:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH2W-0003h7-00 for idr@ietf.org; Thu, 29 Apr 2004 15:17:45 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJH1y-0003ce-00 for idr@ietf.org; Thu, 29 Apr 2004 15:17:10 -0400 Received: from camail03.ca.alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id i3TJHBaC022913 for ; Thu, 29 Apr 2004 15:17:12 -0400 (EDT) Received: from alcatel.com ([138.120.234.32]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HWY5KN00.BDU; Thu, 29 Apr 2004 15:17:11 -0400 Message-ID: <40915437.12CA79AA@alcatel.com> From: Cheng-Yin Lee Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zinin@psg.com, idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Content-Type: text/plain; charset=us-ascii 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: Thu, 29 Apr 2004 15:15:03 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hello, Alex Zinin wrote: >>2.2. BGP Algorithms >> >> >> BGP uses an algorithm that is neither a pure distance vector >> algorithm or a pure link state algorithm. It is instead a modified >> distance vector algorithm referred to as a "Path Vector" algorithm >> that uses path information to avoid traditional distance vector >> problems. Each route within BGP pairs destination with path >> information to that destination. Path information (also known as >> AS_PATH information) is stored within the AS_PATH attribute in BGP. >> This allows BGP to reconstruct large portions of overall topology >> whenever required. >> >> > >I've always been uncomfortable with documents saying that BGP reconstructs the >overall topology. It doesn't really do this like the link-state protocols do, >for example. > > Is this sentence "This allows BGP to reconstruct large portions of overall topology ...." talking about using AS_PATH as topology information or reconstructing routes/paths? >>6.1.1. CPU utilization >> >> >> An important and fundamental feature of BGP is that BGP's CPU >> utilization depends only on the stability of the Internet. If the >> Internet is stable, then the only link bandwidth and router CPU >> cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE >> messages. The KEEPALIVE messages are exchanged only between peers. >> The suggested frequency of the exchange is 30 seconds. The KEEPALIVE >> messages are quite short (19 octets), and require virtually no >> processing. As a result, the bandwidth consumed by the KEEPALIVE >> messages is about 5 bits/sec. Operational experience confirms that >> the overhead (in terms of bandwidth and CPU) associated with the >> KEEPALIVE messages should be viewed as negligible. >> >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The >> >> > >While theoretically the text is correct and we could talk about periods of >stability and instability of the Internet, I wonder if this text is still >applicable from the practical perspective. I.e., the continuous churn that the >Internet BGP speakers experience ensures that they practically always have >something to process. > >Probably instead of talking about periods of "Internet stability" and "Internet >instability" we could talk about something like "periods of stable state among >BGP speakers when they do no have new updates to communicate to each other". > > > >>Meyer and Patel Section 6.1.1. [Page 10] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> greatest overhead per UPDATE message occurs when each UPDATE message >> contains only a single network. It should be pointed out that in >> practice routing changes exhibit strong locality with respect to the >> AS path. That is, routes that change are likely to have common AS >> path. In this case, multiple networks can be grouped into a single >> UPDATE message, thus significantly reducing the amount of bandwidth >> required (see also Appendix F.1 of [BGP4]). >> >> Since in the steady state the link bandwidth and router CPU cycles >> consumed by the BGP protocol are dependent only on the stability of >> the Internet, it follows that BGP should have no scaling problems in >> the areas of link bandwidth and router CPU utilization. >> >> > >Not sure I follow here. What is meant by the "steady state" here? If it means >convergence on a stable topology after the initial exchange of updates, then why >talk about "stability of the Internet"? > > I took this to mean that whenever a BGP session starts, there's a > potentially long initial exchange of routes, and we mean to exclude > that startup transient. > > But, of course, we're back to the "stable Internet" paradigm. :^( >In other words, if the Internet is >unstable then can we say that the BGP speakers are in steady state? In the lack >of topology changes, it seems that the consumption should instead depend on the >number of peers (affects KEEPALIVE processing) and the number of persistently >oscillating routes potentially present in the network... > I agree the term Internet instability may not be clear enough in this draft. It seems that the draft is saying : BGP CPU's utilization depends mostly on number of route exchanges and KEEPALIVE message processing is not significant [The route exchanges can be due to a topology change, router startup, configuration changes, oscillating routes, ..... And oscillating routes may be triggered by topology change, router startup, configuration changes .....] ? If that's the case, instead of saying Internet stability or instability as follows : "If the Internet is stable, then the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages. " perhaps the draft could say something along this line : "If there are no route exchanges, then the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages". > that as the Internet grows, the overall stability of the inter-AS > connectivity of the Internet can be controlled. > Please specify how it is assumed to be "controlled", e.g. through > operational practices. > I believe historically this meant route-flap damping I thought route-flap damping may also slow down route convergence (i.e. may cause instability in turn...) Regards Cheng-Yin _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 29 16:09:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25261 for ; Thu, 29 Apr 2004 16:09:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHcc-0005ZD-1i for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 15:55:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJt2pR021399 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 15:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHUZ-0003U9-Kg for idr-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:46: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 PAA24163 for ; Thu, 29 Apr 2004 15:46:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHUT-0005v8-24 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 15:46:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHTP-0005r5-00 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 15:45:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHSn-0005nU-00; Thu, 29 Apr 2004 15:44:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHDD-0006pu-BQ; Thu, 29 Apr 2004 15:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH3N-0001pm-In for idr@optimus.ietf.org; Thu, 29 Apr 2004 15:18:37 -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 PAA21769 for ; Thu, 29 Apr 2004 15:18:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH3H-0003kb-0v for idr@ietf.org; Thu, 29 Apr 2004 15:18:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH2W-0003h7-00 for idr@ietf.org; Thu, 29 Apr 2004 15:17:45 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJH1y-0003ce-00 for idr@ietf.org; Thu, 29 Apr 2004 15:17:10 -0400 Received: from camail03.ca.alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id i3TJHBaC022913 for ; Thu, 29 Apr 2004 15:17:12 -0400 (EDT) Received: from alcatel.com ([138.120.234.32]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HWY5KN00.BDU; Thu, 29 Apr 2004 15:17:11 -0400 Message-ID: <40915437.12CA79AA@alcatel.com> From: Cheng-Yin Lee Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zinin@psg.com, idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Content-Type: text/plain; charset=us-ascii 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: Thu, 29 Apr 2004 15:15:03 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Alex Zinin wrote: >>2.2. BGP Algorithms >> >> >> BGP uses an algorithm that is neither a pure distance vector >> algorithm or a pure link state algorithm. It is instead a modified >> distance vector algorithm referred to as a "Path Vector" algorithm >> that uses path information to avoid traditional distance vector >> problems. Each route within BGP pairs destination with path >> information to that destination. Path information (also known as >> AS_PATH information) is stored within the AS_PATH attribute in BGP. >> This allows BGP to reconstruct large portions of overall topology >> whenever required. >> >> > >I've always been uncomfortable with documents saying that BGP reconstructs the >overall topology. It doesn't really do this like the link-state protocols do, >for example. > > Is this sentence "This allows BGP to reconstruct large portions of overall topology ...." talking about using AS_PATH as topology information or reconstructing routes/paths? >>6.1.1. CPU utilization >> >> >> An important and fundamental feature of BGP is that BGP's CPU >> utilization depends only on the stability of the Internet. If the >> Internet is stable, then the only link bandwidth and router CPU >> cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE >> messages. The KEEPALIVE messages are exchanged only between peers. >> The suggested frequency of the exchange is 30 seconds. The KEEPALIVE >> messages are quite short (19 octets), and require virtually no >> processing. As a result, the bandwidth consumed by the KEEPALIVE >> messages is about 5 bits/sec. Operational experience confirms that >> the overhead (in terms of bandwidth and CPU) associated with the >> KEEPALIVE messages should be viewed as negligible. >> >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The >> >> > >While theoretically the text is correct and we could talk about periods of >stability and instability of the Internet, I wonder if this text is still >applicable from the practical perspective. I.e., the continuous churn that the >Internet BGP speakers experience ensures that they practically always have >something to process. > >Probably instead of talking about periods of "Internet stability" and "Internet >instability" we could talk about something like "periods of stable state among >BGP speakers when they do no have new updates to communicate to each other". > > > >>Meyer and Patel Section 6.1.1. [Page 10] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> greatest overhead per UPDATE message occurs when each UPDATE message >> contains only a single network. It should be pointed out that in >> practice routing changes exhibit strong locality with respect to the >> AS path. That is, routes that change are likely to have common AS >> path. In this case, multiple networks can be grouped into a single >> UPDATE message, thus significantly reducing the amount of bandwidth >> required (see also Appendix F.1 of [BGP4]). >> >> Since in the steady state the link bandwidth and router CPU cycles >> consumed by the BGP protocol are dependent only on the stability of >> the Internet, it follows that BGP should have no scaling problems in >> the areas of link bandwidth and router CPU utilization. >> >> > >Not sure I follow here. What is meant by the "steady state" here? If it means >convergence on a stable topology after the initial exchange of updates, then why >talk about "stability of the Internet"? > > I took this to mean that whenever a BGP session starts, there's a > potentially long initial exchange of routes, and we mean to exclude > that startup transient. > > But, of course, we're back to the "stable Internet" paradigm. :^( >In other words, if the Internet is >unstable then can we say that the BGP speakers are in steady state? In the lack >of topology changes, it seems that the consumption should instead depend on the >number of peers (affects KEEPALIVE processing) and the number of persistently >oscillating routes potentially present in the network... > I agree the term Internet instability may not be clear enough in this draft. It seems that the draft is saying : BGP CPU's utilization depends mostly on number of route exchanges and KEEPALIVE message processing is not significant [The route exchanges can be due to a topology change, router startup, configuration changes, oscillating routes, ..... And oscillating routes may be triggered by topology change, router startup, configuration changes .....] ? If that's the case, instead of saying Internet stability or instability as follows : "If the Internet is stable, then the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages. " perhaps the draft could say something along this line : "If there are no route exchanges, then the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages". > that as the Internet grows, the overall stability of the inter-AS > connectivity of the Internet can be controlled. > Please specify how it is assumed to be "controlled", e.g. through > operational practices. > I believe historically this meant route-flap damping I thought route-flap damping may also slow down route convergence (i.e. may cause instability in turn...) Regards Cheng-Yin _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 29 22:58:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20189 for ; Thu, 29 Apr 2004 22:58:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOET-0001rg-Tl for idr-archive@ietf.org; Thu, 29 Apr 2004 22:58:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJODd-0001lr-00 for idr-archive@ietf.org; Thu, 29 Apr 2004 22:57:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJOCi-0001gP-00; Thu, 29 Apr 2004 22:56:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJO7F-0005ZJ-8c; Thu, 29 Apr 2004 22:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJNz5-00043V-Vt for idr@optimus.ietf.org; Thu, 29 Apr 2004 22:42: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 WAA19581 for ; Thu, 29 Apr 2004 22:42:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJNyz-0000U0-9V for idr@ietf.org; Thu, 29 Apr 2004 22:42:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJNy3-0000QH-00 for idr@ietf.org; Thu, 29 Apr 2004 22:41:36 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJNxV-0000IF-00 for idr@ietf.org; Thu, 29 Apr 2004 22:41:01 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5F51F2D4881; Thu, 29 Apr 2004 22:40:30 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26110-01-4; Thu, 29 Apr 2004 22:40:19 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E06E92D4888; Thu, 29 Apr 2004 22:40:18 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U2eIa22113; Thu, 29 Apr 2004 22:40:18 -0400 (EDT) From: Jeffrey Haas To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt Message-ID: <20040429224018.F21778@nexthop.com> References: <200404162121.i3GLLDJ87448@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404162121.i3GLLDJ87448@merlot.juniper.net>; from yakov@juniper.net on Fri, Apr 16, 2004 at 02:21:13PM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 22:40:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Additional nits: > Their modification could potential result in routing loops. s/potential/potentially/ In the changes, also note that you corrected transitive to non-transitive in the introduction. I think ROUTER_ID should be consistently substituted with "BGP Identifier" per the current use in draft-ietf-idr-bgp4-23 one. Using this attribute an RR can identify if the routing information is looped back to the same cluster due to mis- configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST, s/is looped/has looped/ Original text: If the BGP Identifiers of two paths are equal when compared in the route selection, then the path with the shorter CLUSTER_LIST length Suggested change: The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the BGP specification) is modified by inserting the following rule between f and g: The BGP Speaker SHOULD prefer all routes with the shorter CLUSTER_LIST length. If no CLUSTER_LIST path attribute is present, the CLUSTER_LIST length is zero. On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote: > Folks, > > During the Last Call it would be greatly appreciated if folks would > read the document and comment on it to the IDR mailing list. In > other words, we need "yes, looks good" or "should fix this and > that", not just silence. > > Thanks in advance. > > Yakov. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 29 23:07:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20472 for ; Thu, 29 Apr 2004 23:07: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 1BJOJy-0007P2-47 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 23:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U34EX0028457 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 23:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOEc-0006dt-Bs for idr-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 22:58:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20215 for ; Thu, 29 Apr 2004 22:58:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOEV-0001rq-Hw for idr-web-archive@ietf.org; Thu, 29 Apr 2004 22:58:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJODf-0001m6-00 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 22:57:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJOCi-0001gP-00; Thu, 29 Apr 2004 22:56:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJO7F-0005ZJ-8c; Thu, 29 Apr 2004 22:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJNz5-00043V-Vt for idr@optimus.ietf.org; Thu, 29 Apr 2004 22:42: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 WAA19581 for ; Thu, 29 Apr 2004 22:42:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJNyz-0000U0-9V for idr@ietf.org; Thu, 29 Apr 2004 22:42:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJNy3-0000QH-00 for idr@ietf.org; Thu, 29 Apr 2004 22:41:36 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJNxV-0000IF-00 for idr@ietf.org; Thu, 29 Apr 2004 22:41:01 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5F51F2D4881; Thu, 29 Apr 2004 22:40:30 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26110-01-4; Thu, 29 Apr 2004 22:40:19 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E06E92D4888; Thu, 29 Apr 2004 22:40:18 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U2eIa22113; Thu, 29 Apr 2004 22:40:18 -0400 (EDT) From: Jeffrey Haas To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt Message-ID: <20040429224018.F21778@nexthop.com> References: <200404162121.i3GLLDJ87448@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404162121.i3GLLDJ87448@merlot.juniper.net>; from yakov@juniper.net on Fri, Apr 16, 2004 at 02:21:13PM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 22:40:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Additional nits: > Their modification could potential result in routing loops. s/potential/potentially/ In the changes, also note that you corrected transitive to non-transitive in the introduction. I think ROUTER_ID should be consistently substituted with "BGP Identifier" per the current use in draft-ietf-idr-bgp4-23 one. Using this attribute an RR can identify if the routing information is looped back to the same cluster due to mis- configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST, s/is looped/has looped/ Original text: If the BGP Identifiers of two paths are equal when compared in the route selection, then the path with the shorter CLUSTER_LIST length Suggested change: The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the BGP specification) is modified by inserting the following rule between f and g: The BGP Speaker SHOULD prefer all routes with the shorter CLUSTER_LIST length. If no CLUSTER_LIST path attribute is present, the CLUSTER_LIST length is zero. On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote: > Folks, > > During the Last Call it would be greatly appreciated if folks would > read the document and comment on it to the IDR mailing list. In > other words, we need "yes, looks good" or "should fix this and > that", not just silence. > > Thanks in advance. > > Yakov. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Apr 29 23:42:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21811 for ; Thu, 29 Apr 2004 23:42:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOul-0005ep-7M for idr-archive@ietf.org; Thu, 29 Apr 2004 23:42:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJOtd-0005Rt-00 for idr-archive@ietf.org; Thu, 29 Apr 2004 23:41:06 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJOsW-0005Is-00; Thu, 29 Apr 2004 23:39:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJOlR-0008Ar-NG; Thu, 29 Apr 2004 23:32:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOe6-0001tr-5t; Thu, 29 Apr 2004 23:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOYt-0001JV-S8 for idr@optimus.ietf.org; Thu, 29 Apr 2004 23:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21057 for ; Thu, 29 Apr 2004 23:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOYo-0003dp-Fu for idr@ietf.org; Thu, 29 Apr 2004 23:19:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJOXw-0003ZH-00 for idr@ietf.org; Thu, 29 Apr 2004 23:18:41 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJOX3-0003Pn-00 for idr@ietf.org; Thu, 29 Apr 2004 23:17:45 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E539A2D483A for ; Thu, 29 Apr 2004 23:17:19 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26630-01-22 for ; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 724EC2D4888 for ; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U3H8P22174 for idr@ietf.org; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt Message-ID: <20040429231708.H21778@nexthop.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com>; from enke@redback.com on Wed, Apr 28, 2004 at 10:13:29AM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 23:17:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Apr 28, 2004 at 10:13:29AM -0700, Enke Chen wrote: > I would like to request that the draft > be accepted as an IDR WG document. The draft was presented previosuly at an > IDR meeting. The algorithm described in the draft has been deployed for several I would echo many of Tom's comments. Specifically: 1. This doesn't solve med oscillation - or at least I don't think so. 2. Having this as a knob would be handy. Whether this knob is turned on by default is an interesting question and the matter of some debate. 3. By having such a knob, those who prefer deterministic path selection in their network can have it while those who prefer path stability with the caveat that it is temporally deterministic could have their way too - perhaps on a border router basis. Suggested changes: Remove 5.2 Add something along the lines of item 3 above? Be a bit more specific about where in the tie breaking algorithm this goes. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Apr 29 23:56:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22277 for ; Thu, 29 Apr 2004 23:56:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOyU-0004yG-Uu for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 23:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U3k6Sf019104 for idr-archive@odin.ietf.org; Thu, 29 Apr 2004 23:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOus-0004HX-1k for idr-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 23:42: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 XAA21837 for ; Thu, 29 Apr 2004 23:42:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOum-0005ez-Ij for idr-web-archive@ietf.org; Thu, 29 Apr 2004 23:42:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJOtf-0005S8-00 for idr-web-archive@ietf.org; Thu, 29 Apr 2004 23:41:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJOsW-0005Is-00; Thu, 29 Apr 2004 23:39:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJOlR-0008Ar-NG; Thu, 29 Apr 2004 23:32:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOe6-0001tr-5t; Thu, 29 Apr 2004 23:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOYt-0001JV-S8 for idr@optimus.ietf.org; Thu, 29 Apr 2004 23:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21057 for ; Thu, 29 Apr 2004 23:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOYo-0003dp-Fu for idr@ietf.org; Thu, 29 Apr 2004 23:19:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJOXw-0003ZH-00 for idr@ietf.org; Thu, 29 Apr 2004 23:18:41 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJOX3-0003Pn-00 for idr@ietf.org; Thu, 29 Apr 2004 23:17:45 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E539A2D483A for ; Thu, 29 Apr 2004 23:17:19 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26630-01-22 for ; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 724EC2D4888 for ; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U3H8P22174 for idr@ietf.org; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt Message-ID: <20040429231708.H21778@nexthop.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com>; from enke@redback.com on Wed, Apr 28, 2004 at 10:13:29AM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 23:17:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Apr 28, 2004 at 10:13:29AM -0700, Enke Chen wrote: > I would like to request that the draft > be accepted as an IDR WG document. The draft was presented previosuly at an > IDR meeting. The algorithm described in the draft has been deployed for several I would echo many of Tom's comments. Specifically: 1. This doesn't solve med oscillation - or at least I don't think so. 2. Having this as a knob would be handy. Whether this knob is turned on by default is an interesting question and the matter of some debate. 3. By having such a knob, those who prefer deterministic path selection in their network can have it while those who prefer path stability with the caveat that it is temporally deterministic could have their way too - perhaps on a border router basis. Suggested changes: Remove 5.2 Add something along the lines of item 3 above? Be a bit more specific about where in the tie breaking algorithm this goes. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 00:28:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24864 for ; Fri, 30 Apr 2004 00:28:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPdw-0003Hh-0M for idr-archive@ietf.org; Fri, 30 Apr 2004 00:28:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPd5-00038Z-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 00:28:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJPcO-0002yF-00; Fri, 30 Apr 2004 00:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPa9-000351-AV; Fri, 30 Apr 2004 00:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPU2-0002Bx-3B for idr@optimus.ietf.org; Fri, 30 Apr 2004 00:18:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23832 for ; Fri, 30 Apr 2004 00:18:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPTw-0001h8-AR for idr@ietf.org; Fri, 30 Apr 2004 00:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPT3-0001ch-00 for idr@ietf.org; Fri, 30 Apr 2004 00:17:42 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJPSl-0001Y3-00 for idr@ietf.org; Fri, 30 Apr 2004 00:17:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C616A2D488C; Fri, 30 Apr 2004 00:16:57 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27746-01-23; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 95E552D484A; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U4GkW22292; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) From: Jeffrey Haas To: Pekka Savola Cc: Pedro Roque Marques , Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <20040430001646.J21778@nexthop.com> References: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, Apr 22, 2004 at 12:17:53PM +0300 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 00:16:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Apr 22, 2004 at 12:17:53PM +0300, Pekka Savola wrote: > For what it's worth, it seems to me that this memo is a solution > looking for the problem. > > Why do we need this in the first place? To "standardize" commonly > used communities? To give the users more tools to mess up their > routing, or to allow the users to make the ISP's policy more complex? > > I'm skeptical about the usefulness of this approach. FWIW, I think this was proposed for a couple of reasons: Once upon a draft, draft-ietf-grow-bgp-redistribution-00.txt tried to formalize some very common bgp policy that communities are used for. Specific examples are: proxy as-path prepend proxy append no-export proxy append no-announce filters included: to an as to two as's to a cidr prefix (v4 only) to a 4byte as The operations are not novel as the survey that Olivier Bonaventure and Bruno Quoitin did as part of the original GROW draft. The draft was suggested as a way to take common operational procuedure and simplify configuration. The primary objection at the time were: 1. We can't represent ipv6 information due to the length of the extended community. 2. Why don't we just make an uber community and be done with it? Flexible communities adds this as well as adding the concept of neighbor classes and being (well...) flexible enough to accomodate future needs as well as deprecating existing mechanisms. My personal suggestions: o Is the underlying functionality useful regardless of the encoding? o If so, is the encoding clean enough or potentially too cumbersome? o Should we keep the encoding of things like route-target, etc. out of this? > - it might make sense to switch the order of Length and "ASN" fields > for better alignment. I thought this had been mentioned at SF IETF. :-) > Length could also include the ASN field. (Maybe > this would be a more typical TLV encoding?) Perhaps it would be better to simply strip any 4byte ASes upon export when 4byte ASes aren't supported. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 00:37:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25216 for ; Fri, 30 Apr 2004 00: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 1BJPi1-0004J8-HI for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 00:33:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U4X9PO016552 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 00:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPe3-0003yH-AJ for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 00:29:03 -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 AAA24899 for ; Fri, 30 Apr 2004 00:28:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPdx-0003Hu-BA for idr-web-archive@ietf.org; Fri, 30 Apr 2004 00:28:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPd7-00038n-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 00:28:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJPcO-0002yF-00; Fri, 30 Apr 2004 00:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPa9-000351-AV; Fri, 30 Apr 2004 00:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPU2-0002Bx-3B for idr@optimus.ietf.org; Fri, 30 Apr 2004 00:18:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23832 for ; Fri, 30 Apr 2004 00:18:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPTw-0001h8-AR for idr@ietf.org; Fri, 30 Apr 2004 00:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPT3-0001ch-00 for idr@ietf.org; Fri, 30 Apr 2004 00:17:42 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJPSl-0001Y3-00 for idr@ietf.org; Fri, 30 Apr 2004 00:17:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C616A2D488C; Fri, 30 Apr 2004 00:16:57 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27746-01-23; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 95E552D484A; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U4GkW22292; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) From: Jeffrey Haas To: Pekka Savola Cc: Pedro Roque Marques , Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <20040430001646.J21778@nexthop.com> References: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, Apr 22, 2004 at 12:17:53PM +0300 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 00:16:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Apr 22, 2004 at 12:17:53PM +0300, Pekka Savola wrote: > For what it's worth, it seems to me that this memo is a solution > looking for the problem. > > Why do we need this in the first place? To "standardize" commonly > used communities? To give the users more tools to mess up their > routing, or to allow the users to make the ISP's policy more complex? > > I'm skeptical about the usefulness of this approach. FWIW, I think this was proposed for a couple of reasons: Once upon a draft, draft-ietf-grow-bgp-redistribution-00.txt tried to formalize some very common bgp policy that communities are used for. Specific examples are: proxy as-path prepend proxy append no-export proxy append no-announce filters included: to an as to two as's to a cidr prefix (v4 only) to a 4byte as The operations are not novel as the survey that Olivier Bonaventure and Bruno Quoitin did as part of the original GROW draft. The draft was suggested as a way to take common operational procuedure and simplify configuration. The primary objection at the time were: 1. We can't represent ipv6 information due to the length of the extended community. 2. Why don't we just make an uber community and be done with it? Flexible communities adds this as well as adding the concept of neighbor classes and being (well...) flexible enough to accomodate future needs as well as deprecating existing mechanisms. My personal suggestions: o Is the underlying functionality useful regardless of the encoding? o If so, is the encoding clean enough or potentially too cumbersome? o Should we keep the encoding of things like route-target, etc. out of this? > - it might make sense to switch the order of Length and "ASN" fields > for better alignment. I thought this had been mentioned at SF IETF. :-) > Length could also include the ASN field. (Maybe > this would be a more typical TLV encoding?) Perhaps it would be better to simply strip any 4byte ASes upon export when 4byte ASes aren't supported. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 01:05:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26031 for ; Fri, 30 Apr 2004 01:05:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJQDR-0006Rc-DQ for idr-archive@ietf.org; Fri, 30 Apr 2004 01:05:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJQCX-0006MQ-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 01:04:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJQBh-0006Hb-00; Fri, 30 Apr 2004 01:03:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJQ1G-00073a-Kj; Fri, 30 Apr 2004 00:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPz3-0006WW-Ly for idr@optimus.ietf.org; Fri, 30 Apr 2004 00:50: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 AAA25458 for ; Fri, 30 Apr 2004 00:50:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPyx-000526-Js for idr@ietf.org; Fri, 30 Apr 2004 00:50:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPxy-0004xT-00 for idr@ietf.org; Fri, 30 Apr 2004 00:49:39 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJPxm-0004tC-00 for idr@ietf.org; Fri, 30 Apr 2004 00:49:26 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AF6598AABAF; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18738-09; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 1BF348AABAD; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id A7A82979C2; Thu, 29 Apr 2004 21:49:24 -0700 (PDT) To: Thomas Barron Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: Message from Thomas Barron of "Wed, 28 Apr 2004 14:38:30 CDT." From: Enke Chen Message-Id: <20040430044924.A7A82979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 21:49:24 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Tom: Thanks for your comments, and sorry that I forgot to reply to your original message earlier. Please see my comments inline. > Message-Id: > Cc: yakov@juniper.net, skh@nexthop.com > From: Thomas Barron > Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt > To: Enke Chen , idr@ietf.org > > Hi Enke, > > Attached is an email I sent to IDR that discusses some issues around > your draft. I don't think I have seen a reply. > > I will add now that since that note I've discussed and thought a bit > more about your argument in 5.2, and I think it is quite clear (and is > indeed the received opinion nowadays) that the essential ingredient in > these route-oscillation problems is the interaction of Route Reflectors > and IGP costs. MED plays a major role as well. > Using sufficiently high IGP costs between clusters will suffice to stop > the churn both in your scenario and in other scenarios that don't involve > router-id. Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR). Re-configuring the IGP metric is certainly an option. However, changing the IGP metric typically has much larger impact on the network traffic matrix, and may not be desirable or feasible. > Indeed, in your scenario if by chance > the times of arrival correspond in the same order to that determined by > the router-ids the churn is not avoided by your algorithm either (the > proof is tedious, but intuitively: start the scenario with the same > ranking of tie-breakers, just use time-of-arrival instead of router-id; > then realize that this order gets preserved as the oscillation proceeds > because the repeatedly advertised-and-withdrawn route will always be > "newest" and correspond to the largest router id in the original > scenario.) Do you have a specific example? I would like to understand better whether the algorithm is applicable to the example. Unlike the ADD-PATH approach (which is a complete solution), the proposed algorithm is effective only for a subset of route oscillations. > > But as I say in the attached, my argument is really with section 5.2, > not with your overall proposal. There are implementations that provide > a knob to do just what you are documenting and I agree that the BGP > spec should provide for this option. > > Best regards, > > Tom Barron > > > >From idr-admin@ietf.org Mon Nov 10 11:51:50 2003 > From: Tom Barron > To: idr@ietf.org > Cc: Thomas P Barron > Message-ID: <20031110174539.GA166@cfcentral.cisco.com> > > Enke, Srihari, et. al: > > I have some questions about draft-chen-bgp-avoid-transition-00.txt. > I'm glad to see this draft since there are implementations out there > using the route-selection algorithm this draft proposes, and since the > proposed algorith is not what is documented in RFC1771 or in > draft-ietf-idr-bgr4-22.txt section 9.1.2.2. > > First, is it the intent of this draft that the proposed algorithm > should *replace* the algorithm currently documented, or just that > it be added as an option? It is a backward-compatible extension to the base BGP spec.. Whether it is ON or OFF, that is an implementation decision. (If that is the intent of your question.) > > Second, while I think the claim in 5.1 that the proposed algorithm > avoids an unnecessary best path transition is quite straightforward, > there ought to be some discussion of concerns that have been expressed > about the consequent lack of determinism in route selection. See > for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt > and appendix A of "Guidelines for Interdomain Traffic Engineering" by > Feamster, Borkenhagen, and Rexford. I'm not personally convinced > that this local indeterminism is a real big deal, but I do think it > needs some discussion in your draft. As I recall, the only practical concern raised so far is the impact on BGP testing script by the proposed algorithm, and the subject (impact on the testing script) seems to be outside the scope of the document. Please let me know if I have missed any other practical concerns. > > Third, I found the argument at 5.2 to the effect that the proposed > algorithm reduces route oscillation a bit unclear. Maybe just a bit > more text is needed, but it seems to me that the really essential > ingredient in your setup in figure 1 and figure 2 is not the router > ID, but the high intracluster IGP metric. Indeed, though you cite > RFC3345, that work focuses on IGP metrics, not router ID, as a > critical factor for "type 1" oscillation scenarios (yours appears to > be a type 1 variant.) If adjusting IGP metrics is sufficient to fix > both your oscillation scenario and other type 1 scenarios, but > shifting from Router ID selection to the proposed time-of-arrival > algorithm is not sufficient for type 1 scenarios in general, then the > contribution of the proposed algorithm to the route oscillation > problem does not seem very decisive. On the other hand, if using the > proposed time-of-arrival algorithm yields a general solution to > oscillation problems, then this reader at least did not get that from > the draft as currently written. > We will work on adding more text to clarify. > I'm glad you folks wrote this draft. I hope it's clear that I'm > not against your proposal, but rather want to address some gaps > in my own understanding of the issues that surround it. > Some of the gaps are with the text in the document :-) We will work on improving it in the next version. Regards, -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 01:09:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26176 for ; Fri, 30 Apr 2004 01:09: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 1BJQEi-0000cm-Fq for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 01:06:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U56usc002400 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 01:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJQDY-0000MC-W5 for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 01:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26057 for ; Fri, 30 Apr 2004 01:05:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJQDS-0006Rm-Q6 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 01:05:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJQCZ-0006Me-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 01:04:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJQBh-0006Hb-00; Fri, 30 Apr 2004 01:03:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJQ1G-00073a-Kj; Fri, 30 Apr 2004 00:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPz3-0006WW-Ly for idr@optimus.ietf.org; Fri, 30 Apr 2004 00:50: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 AAA25458 for ; Fri, 30 Apr 2004 00:50:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPyx-000526-Js for idr@ietf.org; Fri, 30 Apr 2004 00:50:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPxy-0004xT-00 for idr@ietf.org; Fri, 30 Apr 2004 00:49:39 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJPxm-0004tC-00 for idr@ietf.org; Fri, 30 Apr 2004 00:49:26 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AF6598AABAF; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18738-09; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 1BF348AABAD; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id A7A82979C2; Thu, 29 Apr 2004 21:49:24 -0700 (PDT) To: Thomas Barron Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: Message from Thomas Barron of "Wed, 28 Apr 2004 14:38:30 CDT." From: Enke Chen Message-Id: <20040430044924.A7A82979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 21:49:24 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Tom: Thanks for your comments, and sorry that I forgot to reply to your original message earlier. Please see my comments inline. > Message-Id: > Cc: yakov@juniper.net, skh@nexthop.com > From: Thomas Barron > Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt > To: Enke Chen , idr@ietf.org > > Hi Enke, > > Attached is an email I sent to IDR that discusses some issues around > your draft. I don't think I have seen a reply. > > I will add now that since that note I've discussed and thought a bit > more about your argument in 5.2, and I think it is quite clear (and is > indeed the received opinion nowadays) that the essential ingredient in > these route-oscillation problems is the interaction of Route Reflectors > and IGP costs. MED plays a major role as well. > Using sufficiently high IGP costs between clusters will suffice to stop > the churn both in your scenario and in other scenarios that don't involve > router-id. Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR). Re-configuring the IGP metric is certainly an option. However, changing the IGP metric typically has much larger impact on the network traffic matrix, and may not be desirable or feasible. > Indeed, in your scenario if by chance > the times of arrival correspond in the same order to that determined by > the router-ids the churn is not avoided by your algorithm either (the > proof is tedious, but intuitively: start the scenario with the same > ranking of tie-breakers, just use time-of-arrival instead of router-id; > then realize that this order gets preserved as the oscillation proceeds > because the repeatedly advertised-and-withdrawn route will always be > "newest" and correspond to the largest router id in the original > scenario.) Do you have a specific example? I would like to understand better whether the algorithm is applicable to the example. Unlike the ADD-PATH approach (which is a complete solution), the proposed algorithm is effective only for a subset of route oscillations. > > But as I say in the attached, my argument is really with section 5.2, > not with your overall proposal. There are implementations that provide > a knob to do just what you are documenting and I agree that the BGP > spec should provide for this option. > > Best regards, > > Tom Barron > > > >From idr-admin@ietf.org Mon Nov 10 11:51:50 2003 > From: Tom Barron > To: idr@ietf.org > Cc: Thomas P Barron > Message-ID: <20031110174539.GA166@cfcentral.cisco.com> > > Enke, Srihari, et. al: > > I have some questions about draft-chen-bgp-avoid-transition-00.txt. > I'm glad to see this draft since there are implementations out there > using the route-selection algorithm this draft proposes, and since the > proposed algorith is not what is documented in RFC1771 or in > draft-ietf-idr-bgr4-22.txt section 9.1.2.2. > > First, is it the intent of this draft that the proposed algorithm > should *replace* the algorithm currently documented, or just that > it be added as an option? It is a backward-compatible extension to the base BGP spec.. Whether it is ON or OFF, that is an implementation decision. (If that is the intent of your question.) > > Second, while I think the claim in 5.1 that the proposed algorithm > avoids an unnecessary best path transition is quite straightforward, > there ought to be some discussion of concerns that have been expressed > about the consequent lack of determinism in route selection. See > for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt > and appendix A of "Guidelines for Interdomain Traffic Engineering" by > Feamster, Borkenhagen, and Rexford. I'm not personally convinced > that this local indeterminism is a real big deal, but I do think it > needs some discussion in your draft. As I recall, the only practical concern raised so far is the impact on BGP testing script by the proposed algorithm, and the subject (impact on the testing script) seems to be outside the scope of the document. Please let me know if I have missed any other practical concerns. > > Third, I found the argument at 5.2 to the effect that the proposed > algorithm reduces route oscillation a bit unclear. Maybe just a bit > more text is needed, but it seems to me that the really essential > ingredient in your setup in figure 1 and figure 2 is not the router > ID, but the high intracluster IGP metric. Indeed, though you cite > RFC3345, that work focuses on IGP metrics, not router ID, as a > critical factor for "type 1" oscillation scenarios (yours appears to > be a type 1 variant.) If adjusting IGP metrics is sufficient to fix > both your oscillation scenario and other type 1 scenarios, but > shifting from Router ID selection to the proposed time-of-arrival > algorithm is not sufficient for type 1 scenarios in general, then the > contribution of the proposed algorithm to the route oscillation > problem does not seem very decisive. On the other hand, if using the > proposed time-of-arrival algorithm yields a general solution to > oscillation problems, then this reader at least did not get that from > the draft as currently written. > We will work on adding more text to clarify. > I'm glad you folks wrote this draft. I hope it's clear that I'm > not against your proposal, but rather want to address some gaps > in my own understanding of the issues that surround it. > Some of the gaps are with the text in the document :-) We will work on improving it in the next version. Regards, -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 13:27:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16510 for ; Fri, 30 Apr 2004 13:27:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbnD-0002oP-Kq for idr-archive@ietf.org; Fri, 30 Apr 2004 13:27:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbmI-0002fh-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 13:26:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJblG-0002XN-00; Fri, 30 Apr 2004 13:25:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbi9-0008VK-J1; Fri, 30 Apr 2004 13:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbeK-0007TX-AQ for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:18: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 NAA15841 for ; Fri, 30 Apr 2004 13:18:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbeI-0001yJ-7u for idr@ietf.org; Fri, 30 Apr 2004 13:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbdJ-0001uq-00 for idr@ietf.org; Fri, 30 Apr 2004 13:17:06 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJbcM-0001or-00 for idr@ietf.org; Fri, 30 Apr 2004 13:16:07 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3UHFYl85648; Fri, 30 Apr 2004 10:15:34 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHFQJ27453; Fri, 30 Apr 2004 10:15:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301715.i3UHFQJ27453@merlot.juniper.net> To: Pekka Savola cc: Alex Zinin , ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: Your message of "Thu, 29 Apr 2004 19:35:00 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9409.1083345326.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:15:26 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, > On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > > 2) The definition of active route is bad. This fails in the > > > > situation where you need to export loopbacks/point-to-points to > > > > eBGP, but you have them in youro IGP. The specification does not > > > > consider them active (not used for forwarding), and they aren't > > > > exported. > > > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > > obviously this is no problem. Gargi Nalawade promised to submit > > > > text, but hasn't, and I think Yakov said something about being > > > > willing to incorporate that, but obviously hasn't. > > > > > > > > This was discussed at idr thread: > > > > > > > issue 11.2: active route, again > > > > > > > Otherwise, I think this was operationally good. > > > > > > Sue, Yakov, please check if the ball was dropped re this one. > > > > First of all, the consensus of the WG (as documented in > > draft-ietf-idr-bgp-issues) is to have the following text: > > > > In the context of this document we assume that a BGP speaker > > advertises to its peers only those routes that it itself uses (in > > this context a BGP speaker is said to "use" a BGP route if it is the > > most preferred BGP route and is used in forwarding). All other cases > > are outside the scope of this document. > > > > While this text does not cover the case described by Pekka, it does > > not preclude it either - handling the case described by Pekka > > is just outside the scope of the spec. > > > > With this in mind I suggest that the case described by Pekka > > should be covered in a separate Internet Draft. > > I think this is operationally a rather common (or even very common) > scenario, and it would seem very disadvantageous not to tackle it in > this specification. Further, there's major deployment of it (maybe > even multi-vendor -- probably) so there is considerable proof that it > works. > > It should be the default behaviour of BGP as that's which makes the > most sense, operationally. "BGP route is ... used by forwarding" does > not sufficiently cover the fact that people do use IGPs and there's > often overlap with IGP and BGP :). People do use IGPs, and there is interaction between IGPs and BGP. It is just that the based BGP protocol spec is *not* the place to document the interaction between BGP and IGPs. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 13:33:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17248 for ; Fri, 30 Apr 2004 13:33:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbsx-0003NW-5S for idr-archive@ietf.org; Fri, 30 Apr 2004 13:33:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbrz-0003Jd-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 13:32:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbrj-0003GO-00; Fri, 30 Apr 2004 13:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbkz-0000co-Vg; Fri, 30 Apr 2004 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbhN-0008P2-0u for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:21:17 -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 NAA15936 for ; Fri, 30 Apr 2004 13:21:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbhL-0002Av-15 for idr@ietf.org; Fri, 30 Apr 2004 13:21:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbgK-00025e-00 for idr@ietf.org; Fri, 30 Apr 2004 13:20:13 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJbfT-0001za-00 for idr@ietf.org; Fri, 30 Apr 2004 13:19:19 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UHIiZ21669; Fri, 30 Apr 2004 20:18:44 +0300 From: Pekka Savola To: Yakov Rekhter cc: Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: <200404301715.i3UHFQJ27453@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 20:18:44 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 30 Apr 2004, Yakov Rekhter wrote: > > I think this is operationally a rather common (or even very common) > > scenario, and it would seem very disadvantageous not to tackle it in > > this specification. Further, there's major deployment of it (maybe > > even multi-vendor -- probably) so there is considerable proof that it > > works. > > > > It should be the default behaviour of BGP as that's which makes the > > most sense, operationally. "BGP route is ... used by forwarding" does > > not sufficiently cover the fact that people do use IGPs and there's > > often overlap with IGP and BGP :). > > People do use IGPs, and there is interaction between IGPs and BGP. > > It is just that the based BGP protocol spec is *not* the place to > document the interaction between BGP and IGPs. I have to disagree here. BGP is useless without IGP. Failing to consider that would mean a specifition disconnected from the reality. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 13:38:35 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17516 for ; Fri, 30 Apr 2004 13:38: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 1BJbvS-00028b-OA for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:35:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHZoi3008217 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbnG-0000yf-UM for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16536 for ; Fri, 30 Apr 2004 13:27:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbnE-0002oa-Uw for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:27:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbmK-0002fx-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:26:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJblG-0002XN-00; Fri, 30 Apr 2004 13:25:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbi9-0008VK-J1; Fri, 30 Apr 2004 13:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbeK-0007TX-AQ for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:18: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 NAA15841 for ; Fri, 30 Apr 2004 13:18:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbeI-0001yJ-7u for idr@ietf.org; Fri, 30 Apr 2004 13:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbdJ-0001uq-00 for idr@ietf.org; Fri, 30 Apr 2004 13:17:06 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJbcM-0001or-00 for idr@ietf.org; Fri, 30 Apr 2004 13:16:07 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3UHFYl85648; Fri, 30 Apr 2004 10:15:34 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHFQJ27453; Fri, 30 Apr 2004 10:15:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301715.i3UHFQJ27453@merlot.juniper.net> To: Pekka Savola cc: Alex Zinin , ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: Your message of "Thu, 29 Apr 2004 19:35:00 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9409.1083345326.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:15:26 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, > On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > > 2) The definition of active route is bad. This fails in the > > > > situation where you need to export loopbacks/point-to-points to > > > > eBGP, but you have them in youro IGP. The specification does not > > > > consider them active (not used for forwarding), and they aren't > > > > exported. > > > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > > obviously this is no problem. Gargi Nalawade promised to submit > > > > text, but hasn't, and I think Yakov said something about being > > > > willing to incorporate that, but obviously hasn't. > > > > > > > > This was discussed at idr thread: > > > > > > > issue 11.2: active route, again > > > > > > > Otherwise, I think this was operationally good. > > > > > > Sue, Yakov, please check if the ball was dropped re this one. > > > > First of all, the consensus of the WG (as documented in > > draft-ietf-idr-bgp-issues) is to have the following text: > > > > In the context of this document we assume that a BGP speaker > > advertises to its peers only those routes that it itself uses (in > > this context a BGP speaker is said to "use" a BGP route if it is the > > most preferred BGP route and is used in forwarding). All other cases > > are outside the scope of this document. > > > > While this text does not cover the case described by Pekka, it does > > not preclude it either - handling the case described by Pekka > > is just outside the scope of the spec. > > > > With this in mind I suggest that the case described by Pekka > > should be covered in a separate Internet Draft. > > I think this is operationally a rather common (or even very common) > scenario, and it would seem very disadvantageous not to tackle it in > this specification. Further, there's major deployment of it (maybe > even multi-vendor -- probably) so there is considerable proof that it > works. > > It should be the default behaviour of BGP as that's which makes the > most sense, operationally. "BGP route is ... used by forwarding" does > not sufficiently cover the fact that people do use IGPs and there's > often overlap with IGP and BGP :). People do use IGPs, and there is interaction between IGPs and BGP. It is just that the based BGP protocol spec is *not* the place to document the interaction between BGP and IGPs. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 13:39:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17539 for ; Fri, 30 Apr 2004 13:39:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbyd-0003jR-7m for idr-archive@ietf.org; Fri, 30 Apr 2004 13:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbxj-0003gq-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 13:38:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbws-0003eQ-00; Fri, 30 Apr 2004 13:37:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbor-0001El-54; Fri, 30 Apr 2004 13:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbkA-0000Oj-R5 for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:24: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 NAA16156 for ; Fri, 30 Apr 2004 13:24:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbk8-0002Qt-Q3 for idr@ietf.org; Fri, 30 Apr 2004 13:24:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbjI-0002N9-00 for idr@ietf.org; Fri, 30 Apr 2004 13:23:17 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJbiO-0002EV-00 for idr@ietf.org; Fri, 30 Apr 2004 13:22:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3UHLol85668 for ; Fri, 30 Apr 2004 10:21:50 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHLjJ28638 for ; Fri, 30 Apr 2004 10:21:45 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301721.i3UHLjJ28638@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10769.1083345705.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document 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, 30 Apr 2004 10:21:45 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks We receive a request to accept draft-chen-bgp-avoid-transition-01.txt as an IDR WG document. Please comment to the list. The deadline for comments is May 14, 2004. Yakov. ------- Forwarded Message Date: Wed, 28 Apr 2004 10:13:29 -0700 From: Enke Chen To: yakov@juniper.net, skh@nexthop.com cc: idr@ietf.org Subject: draft-chen-bgp-avoid-transition-01.txt Hi, Yakov and Sue: I would like to request that the draft be accepted as an IDR WG document. The draft was presented previosuly at an IDR meeting. The algorithm described in the draft has been deployed for several years. Thanks. -- Enke - ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoid BGP Best Path Transition from One External to A nother Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt - ------- End of Forwarded Message ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 13:43:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17724 for ; Fri, 30 Apr 2004 13:43: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 1BJbxe-0002mJ-13 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:38:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHc5xm010671 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbt1-0001ia-Ag for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:33: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 NAA17274 for ; Fri, 30 Apr 2004 13:33:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbsz-0003Nm-93 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:33:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbs0-0003Ju-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:32:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbrj-0003GO-00; Fri, 30 Apr 2004 13:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbkz-0000co-Vg; Fri, 30 Apr 2004 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbhN-0008P2-0u for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:21:17 -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 NAA15936 for ; Fri, 30 Apr 2004 13:21:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbhL-0002Av-15 for idr@ietf.org; Fri, 30 Apr 2004 13:21:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbgK-00025e-00 for idr@ietf.org; Fri, 30 Apr 2004 13:20:13 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJbfT-0001za-00 for idr@ietf.org; Fri, 30 Apr 2004 13:19:19 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UHIiZ21669; Fri, 30 Apr 2004 20:18:44 +0300 From: Pekka Savola To: Yakov Rekhter cc: Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: <200404301715.i3UHFQJ27453@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 20:18:44 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 30 Apr 2004, Yakov Rekhter wrote: > > I think this is operationally a rather common (or even very common) > > scenario, and it would seem very disadvantageous not to tackle it in > > this specification. Further, there's major deployment of it (maybe > > even multi-vendor -- probably) so there is considerable proof that it > > works. > > > > It should be the default behaviour of BGP as that's which makes the > > most sense, operationally. "BGP route is ... used by forwarding" does > > not sufficiently cover the fact that people do use IGPs and there's > > often overlap with IGP and BGP :). > > People do use IGPs, and there is interaction between IGPs and BGP. > > It is just that the based BGP protocol spec is *not* the place to > document the interaction between BGP and IGPs. I have to disagree here. BGP is useless without IGP. Failing to consider that would mean a specifition disconnected from the reality. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 13:55:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18091 for ; Fri, 30 Apr 2004 13:55: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 1BJc2x-0003qb-HV for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:43:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHhZX0014786 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:43:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbyg-00038d-Sr for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:39: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 NAA17573 for ; Fri, 30 Apr 2004 13:39:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbye-0003jb-Kf for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:39:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbxk-0003h6-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:38:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbws-0003eQ-00; Fri, 30 Apr 2004 13:37:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbor-0001El-54; Fri, 30 Apr 2004 13:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbkA-0000Oj-R5 for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:24: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 NAA16156 for ; Fri, 30 Apr 2004 13:24:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbk8-0002Qt-Q3 for idr@ietf.org; Fri, 30 Apr 2004 13:24:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbjI-0002N9-00 for idr@ietf.org; Fri, 30 Apr 2004 13:23:17 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJbiO-0002EV-00 for idr@ietf.org; Fri, 30 Apr 2004 13:22:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3UHLol85668 for ; Fri, 30 Apr 2004 10:21:50 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHLjJ28638 for ; Fri, 30 Apr 2004 10:21:45 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301721.i3UHLjJ28638@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10769.1083345705.1@juniper.net> From: Yakov Rekhter Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document 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, 30 Apr 2004 10:21:45 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks We receive a request to accept draft-chen-bgp-avoid-transition-01.txt as an IDR WG document. Please comment to the list. The deadline for comments is May 14, 2004. Yakov. ------- Forwarded Message Date: Wed, 28 Apr 2004 10:13:29 -0700 From: Enke Chen To: yakov@juniper.net, skh@nexthop.com cc: idr@ietf.org Subject: draft-chen-bgp-avoid-transition-01.txt Hi, Yakov and Sue: I would like to request that the draft be accepted as an IDR WG document. The draft was presented previosuly at an IDR meeting. The algorithm described in the draft has been deployed for several years. Thanks. -- Enke - ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoid BGP Best Path Transition from One External to A nother Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt - ------- End of Forwarded Message ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 13:57:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18424 for ; Fri, 30 Apr 2004 13:57:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcGW-00050M-V7 for idr-archive@ietf.org; Fri, 30 Apr 2004 13:57:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcF9-0004k6-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 13:56:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcDi-0004Sn-01; Fri, 30 Apr 2004 13:54:42 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJc1N-0005x4-B5; Fri, 30 Apr 2004 13:41:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbxc-0002lT-Mm; Fri, 30 Apr 2004 13:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbp5-0001Ez-Jv for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:29:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16790 for ; Fri, 30 Apr 2004 13:29:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbp3-0002zo-Hz for idr@ietf.org; Fri, 30 Apr 2004 13:29:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbo5-0002v8-00 for idr@ietf.org; Fri, 30 Apr 2004 13:28:14 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BJbnE-0002k6-00 for idr@ietf.org; Fri, 30 Apr 2004 13:27:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3UHQnBm035999; Fri, 30 Apr 2004 10:26:49 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHQnJ30213; Fri, 30 Apr 2004 10:26:49 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301726.i3UHQnJ30213@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11789.1083346009.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:26:49 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks > We receive a request to accept draft-lange-flexible-bgp-communities-02.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 28, 2004. The draft didn't generate enough support to justify its acceptance as an IDR WG document. Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 14:06:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18811 for ; Fri, 30 Apr 2004 14:06:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcIc-0005yA-Eg for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:59:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHxk2U022938 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 13:59:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcGb-0005cF-1O for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:57:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18456 for ; Fri, 30 Apr 2004 13:57:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcGY-00050Y-Ow for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:57:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcFB-0004kT-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 13:56:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcDi-0004Sn-01; Fri, 30 Apr 2004 13:54:42 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJc1N-0005x4-B5; Fri, 30 Apr 2004 13:41:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbxc-0002lT-Mm; Fri, 30 Apr 2004 13:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbp5-0001Ez-Jv for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:29:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16790 for ; Fri, 30 Apr 2004 13:29:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbp3-0002zo-Hz for idr@ietf.org; Fri, 30 Apr 2004 13:29:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbo5-0002v8-00 for idr@ietf.org; Fri, 30 Apr 2004 13:28:14 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BJbnE-0002k6-00 for idr@ietf.org; Fri, 30 Apr 2004 13:27:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3UHQnBm035999; Fri, 30 Apr 2004 10:26:49 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHQnJ30213; Fri, 30 Apr 2004 10:26:49 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301726.i3UHQnJ30213@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11789.1083346009.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:26:49 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks > We receive a request to accept draft-lange-flexible-bgp-communities-02.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 28, 2004. The draft didn't generate enough support to justify its acceptance as an IDR WG document. Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 14:13:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19357 for ; Fri, 30 Apr 2004 14:13:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcVy-0006FP-Rn for idr-archive@ietf.org; Fri, 30 Apr 2004 14:13:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcUU-0005xR-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 14:12:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcTX-0005nH-03; Fri, 30 Apr 2004 14:11:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJcLs-0006g4-Dk; Fri, 30 Apr 2004 14:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcGu-0005eA-Ue; Fri, 30 Apr 2004 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcFv-0005RO-VS for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18200 for ; Fri, 30 Apr 2004 13:56:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcFt-0004sO-LS for idr@ietf.org; Fri, 30 Apr 2004 13:56:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcEN-0004am-00 for idr@ietf.org; Fri, 30 Apr 2004 13:55:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcDE-0004Sn-00 for idr@ietf.org; Fri, 30 Apr 2004 13:54:12 -0400 Received: from prattle.redback.com ([155.53.12.9]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJc3X-00061s-Qv for idr@ietf.org; Fri, 30 Apr 2004 13:44:11 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D281B259469; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-06; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 4D91125946B; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 3875F15D3C3; Fri, 30 Apr 2004 10:43:37 -0700 (PDT) To: Jeffrey Haas Cc: Yakov Rekhter , idr@ietf.org, enke@redback.com Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Message from Jeffrey Haas of "Thu, 29 Apr 2004 22:40:18 EDT." <20040429224018.F21778@nexthop.com> From: Enke Chen Message-Id: <20040430174337.3875F15D3C3@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:43:36 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Jeff: > From: Jeffrey Haas > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt > Message-ID: <20040429224018.F21778@nexthop.com> > References: <200404162121.i3GLLDJ87448@merlot.juniper.net> > > Additional nits: > > Their modification could potential result in routing loops. > > s/potential/potentially/ > > In the changes, also note that you corrected transitive to > non-transitive in the introduction. > > I think ROUTER_ID should be consistently substituted with "BGP Identifier" > per the current use in draft-ietf-idr-bgp4-23 Ok. > > one. Using this attribute an RR can identify if the routing > information is looped back to the same cluster due to mis- > configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST, > > > s/is looped/has looped/ Ok. > > Original text: > If the BGP Identifiers of two paths are equal when compared in the > route selection, then the path with the shorter CLUSTER_LIST length > > Suggested change: > The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the > BGP specification) is modified by inserting the following rule > between f and g: > > The BGP Speaker SHOULD prefer all routes with the shorter > CLUSTER_LIST length. If no CLUSTER_LIST path attribute is present, > the CLUSTER_LIST length is zero. will revise the text along these lines. Thanks. -- Enke > > On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote: > > Folks, > > > > During the Last Call it would be greatly appreciated if folks would > > read the document and comment on it to the IDR mailing list. In > > other words, we need "yes, looks good" or "should fix this and > > that", not just silence. > > > > Thanks in advance. > > > > Yakov. > > -- > Jeff Haas > NextHop Technologies > > _______________________________________________ > 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 Fri Apr 30 14:23:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19850 for ; Fri, 30 Apr 2004 14:23:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcdu-0000u2-E8 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 14:21:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UILksM003463 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 14:21:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcW2-0008IH-K4 for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:13:38 -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 OAA19369 for ; Fri, 30 Apr 2004 14:13:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcVz-0006FY-KO for idr-web-archive@ietf.org; Fri, 30 Apr 2004 14:13:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcUW-0005xf-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 14:12:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcTX-0005nH-03; Fri, 30 Apr 2004 14:11:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJcLs-0006g4-Dk; Fri, 30 Apr 2004 14:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcGu-0005eA-Ue; Fri, 30 Apr 2004 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcFv-0005RO-VS for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18200 for ; Fri, 30 Apr 2004 13:56:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcFt-0004sO-LS for idr@ietf.org; Fri, 30 Apr 2004 13:56:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcEN-0004am-00 for idr@ietf.org; Fri, 30 Apr 2004 13:55:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcDE-0004Sn-00 for idr@ietf.org; Fri, 30 Apr 2004 13:54:12 -0400 Received: from prattle.redback.com ([155.53.12.9]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJc3X-00061s-Qv for idr@ietf.org; Fri, 30 Apr 2004 13:44:11 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D281B259469; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-06; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 4D91125946B; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 3875F15D3C3; Fri, 30 Apr 2004 10:43:37 -0700 (PDT) To: Jeffrey Haas Cc: Yakov Rekhter , idr@ietf.org, enke@redback.com Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Message from Jeffrey Haas of "Thu, 29 Apr 2004 22:40:18 EDT." <20040429224018.F21778@nexthop.com> From: Enke Chen Message-Id: <20040430174337.3875F15D3C3@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:43:36 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Jeff: > From: Jeffrey Haas > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt > Message-ID: <20040429224018.F21778@nexthop.com> > References: <200404162121.i3GLLDJ87448@merlot.juniper.net> > > Additional nits: > > Their modification could potential result in routing loops. > > s/potential/potentially/ > > In the changes, also note that you corrected transitive to > non-transitive in the introduction. > > I think ROUTER_ID should be consistently substituted with "BGP Identifier" > per the current use in draft-ietf-idr-bgp4-23 Ok. > > one. Using this attribute an RR can identify if the routing > information is looped back to the same cluster due to mis- > configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST, > > > s/is looped/has looped/ Ok. > > Original text: > If the BGP Identifiers of two paths are equal when compared in the > route selection, then the path with the shorter CLUSTER_LIST length > > Suggested change: > The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the > BGP specification) is modified by inserting the following rule > between f and g: > > The BGP Speaker SHOULD prefer all routes with the shorter > CLUSTER_LIST length. If no CLUSTER_LIST path attribute is present, > the CLUSTER_LIST length is zero. will revise the text along these lines. Thanks. -- Enke > > On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote: > > Folks, > > > > During the Last Call it would be greatly appreciated if folks would > > read the document and comment on it to the IDR mailing list. In > > other words, we need "yes, looks good" or "should fix this and > > that", not just silence. > > > > Thanks in advance. > > > > Yakov. > > -- > Jeff Haas > NextHop Technologies > > _______________________________________________ > 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 Fri Apr 30 14:30:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20743 for ; Fri, 30 Apr 2004 14:30:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcmB-00004t-BI for idr-archive@ietf.org; Fri, 30 Apr 2004 14:30:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJclR-0007nZ-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 14:29:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJckd-0007ib-00; Fri, 30 Apr 2004 14:28:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceF-00013P-2J; Fri, 30 Apr 2004 14:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcWX-0008J5-EV for idr@optimus.ietf.org; Fri, 30 Apr 2004 14:14: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 OAA19498 for ; Fri, 30 Apr 2004 14:14:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcWU-0006J9-Ts for idr@ietf.org; Fri, 30 Apr 2004 14:14:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcV3-000659-00 for idr@ietf.org; Fri, 30 Apr 2004 14:12:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcTg-0005pX-04 for idr@ietf.org; Fri, 30 Apr 2004 14:11:12 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJcFk-0006VX-MU for idr@ietf.org; Fri, 30 Apr 2004 13:56:48 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3UHuHBm036112 for ; Fri, 30 Apr 2004 10:56:17 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHuHJ37685 for ; Fri, 30 Apr 2004 10:56:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301756.i3UHuHJ37685@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18739.1083347777.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:56:17 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks > Folks, > > This is to start the IDR WG Last Call on advancing > draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. > > The Last Call ends April 28. The WG Last Call is over. Many thanks to the folks who read and commented on the document !!! The authors of the document are going to incorporate the comments received during the WG Last Call and re-issue a revised draft. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 14:32:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20847 for ; Fri, 30 Apr 2004 14:32:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJco2-0000Eh-1k for idr-archive@ietf.org; Fri, 30 Apr 2004 14:32:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcn8-0000AQ-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 14:31:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJcmb-00006f-00; Fri, 30 Apr 2004 14:30:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceN-00016A-68; Fri, 30 Apr 2004 14:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcZS-00008U-Uc for idr@optimus.ietf.org; Fri, 30 Apr 2004 14:17: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 OAA19678 for ; Fri, 30 Apr 2004 14:17:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcZQ-0006Zz-E1 for idr@ietf.org; Fri, 30 Apr 2004 14:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcYS-0006VY-00 for idr@ietf.org; Fri, 30 Apr 2004 14:16:08 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BJcXU-0006Oi-00 for idr@ietf.org; Fri, 30 Apr 2004 14:15:08 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3UIEc5O029460; Fri, 30 Apr 2004 11:14:38 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3UIEcOB029457; Fri, 30 Apr 2004 11:14:38 -0700 (PDT) Message-Id: <200404301814.i3UIEcOB029457@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Yakov Rekhter , Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: References: <200404301715.i3UHFQJ27453@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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: Fri, 30 Apr 2004 11:14:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola writes: > On Fri, 30 Apr 2004, Yakov Rekhter wrote: >> > I think this is operationally a rather common (or even very >> common) > scenario, and it would seem very disadvantageous not to >> tackle it in > this specification. Further, there's major >> deployment of it (maybe > even multi-vendor -- probably) so there >> is considerable proof that it > works. > > It should be the >> default behaviour of BGP as that's which makes the > most sense, >> operationally. "BGP route is ... used by forwarding" does > not >> sufficiently cover the fact that people do use IGPs and there's > >> often overlap with IGP and BGP :). >> >> People do use IGPs, and there is interaction between IGPs and BGP. >> >> It is just that the based BGP protocol spec is *not* the place to >> document the interaction between BGP and IGPs. > I have to disagree here. BGP is useless without IGP. Failing to > consider that would mean a specifition disconnected from the > reality. Pekka, BGP is only one of the miriad of components necessary in a router. There are advantages in documenting interactions between such components but these are typically not done in the base specification. One simply cannot put all the bits of information required to make bgp "useful" in the base specification and still have a readable document. moreever the iteraction procedures that you seem to want to document are not something the wg has achieved consensus on. there are still different opinions on this topic and different deployed behaviours. Thus including this topic in the base protocol spec seems to me to be contrary to the original goals of revising the specification. I would also like to point out that several outher people have expressed the opinion that this topic should be left out of the base spec. In fact i would claim that there is consensus on that ammong the wg. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 14:36:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21208 for ; Fri, 30 Apr 2004 14:36: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 1BJcoc-0003BF-TN for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 14:32:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UIWoui012220 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 14:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcmF-0002O2-Bw for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:30:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20769 for ; Fri, 30 Apr 2004 14:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcmC-000054-NI for idr-web-archive@ietf.org; Fri, 30 Apr 2004 14:30:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJclS-0007nn-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 14:29:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJckd-0007ib-00; Fri, 30 Apr 2004 14:28:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceF-00013P-2J; Fri, 30 Apr 2004 14:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcWX-0008J5-EV for idr@optimus.ietf.org; Fri, 30 Apr 2004 14:14: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 OAA19498 for ; Fri, 30 Apr 2004 14:14:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcWU-0006J9-Ts for idr@ietf.org; Fri, 30 Apr 2004 14:14:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcV3-000659-00 for idr@ietf.org; Fri, 30 Apr 2004 14:12:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcTg-0005pX-04 for idr@ietf.org; Fri, 30 Apr 2004 14:11:12 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJcFk-0006VX-MU for idr@ietf.org; Fri, 30 Apr 2004 13:56:48 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3UHuHBm036112 for ; Fri, 30 Apr 2004 10:56:17 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHuHJ37685 for ; Fri, 30 Apr 2004 10:56:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301756.i3UHuHJ37685@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18739.1083347777.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 10:56:17 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks > Folks, > > This is to start the IDR WG Last Call on advancing > draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. > > The Last Call ends April 28. The WG Last Call is over. Many thanks to the folks who read and commented on the document !!! The authors of the document are going to incorporate the comments received during the WG Last Call and re-issue a revised draft. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 14:36:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21233 for ; Fri, 30 Apr 2004 14:36: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 1BJcoe-0003CL-Lm for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 14:32:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UIWqIK012288 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 14:32:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJco6-0002tT-3M for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:32:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20870 for ; Fri, 30 Apr 2004 14:32:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJco3-0000Er-9e for idr-web-archive@ietf.org; Fri, 30 Apr 2004 14:32:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcnA-0000Ag-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 14:31:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJcmb-00006f-00; Fri, 30 Apr 2004 14:30:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceN-00016A-68; Fri, 30 Apr 2004 14:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcZS-00008U-Uc for idr@optimus.ietf.org; Fri, 30 Apr 2004 14:17: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 OAA19678 for ; Fri, 30 Apr 2004 14:17:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcZQ-0006Zz-E1 for idr@ietf.org; Fri, 30 Apr 2004 14:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcYS-0006VY-00 for idr@ietf.org; Fri, 30 Apr 2004 14:16:08 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BJcXU-0006Oi-00 for idr@ietf.org; Fri, 30 Apr 2004 14:15:08 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3UIEc5O029460; Fri, 30 Apr 2004 11:14:38 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3UIEcOB029457; Fri, 30 Apr 2004 11:14:38 -0700 (PDT) Message-Id: <200404301814.i3UIEcOB029457@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Yakov Rekhter , Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: References: <200404301715.i3UHFQJ27453@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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: Fri, 30 Apr 2004 11:14:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola writes: > On Fri, 30 Apr 2004, Yakov Rekhter wrote: >> > I think this is operationally a rather common (or even very >> common) > scenario, and it would seem very disadvantageous not to >> tackle it in > this specification. Further, there's major >> deployment of it (maybe > even multi-vendor -- probably) so there >> is considerable proof that it > works. > > It should be the >> default behaviour of BGP as that's which makes the > most sense, >> operationally. "BGP route is ... used by forwarding" does > not >> sufficiently cover the fact that people do use IGPs and there's > >> often overlap with IGP and BGP :). >> >> People do use IGPs, and there is interaction between IGPs and BGP. >> >> It is just that the based BGP protocol spec is *not* the place to >> document the interaction between BGP and IGPs. > I have to disagree here. BGP is useless without IGP. Failing to > consider that would mean a specifition disconnected from the > reality. Pekka, BGP is only one of the miriad of components necessary in a router. There are advantages in documenting interactions between such components but these are typically not done in the base specification. One simply cannot put all the bits of information required to make bgp "useful" in the base specification and still have a readable document. moreever the iteraction procedures that you seem to want to document are not something the wg has achieved consensus on. there are still different opinions on this topic and different deployed behaviours. Thus including this topic in the base protocol spec seems to me to be contrary to the original goals of revising the specification. I would also like to point out that several outher people have expressed the opinion that this topic should be left out of the base spec. In fact i would claim that there is consensus on that ammong the wg. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 16:59:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02635 for ; Fri, 30 Apr 2004 16:59:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJf6V-0000ar-Hg for idr-archive@ietf.org; Fri, 30 Apr 2004 16:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJf5h-0000V2-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 16:58:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJf51-0000Oq-00; Fri, 30 Apr 2004 16:57:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJf4z-0001u6-9v; Fri, 30 Apr 2004 16:57:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe7n-0003TS-17; Fri, 30 Apr 2004 15:56:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe0Y-0000X3-BW for idr@optimus.ietf.org; Fri, 30 Apr 2004 15:49: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 PAA26771 for ; Fri, 30 Apr 2004 15:49:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJe0W-0006uv-Rb for idr@ietf.org; Fri, 30 Apr 2004 15:49:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdzY-0006qR-00 for idr@ietf.org; Fri, 30 Apr 2004 15:48:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BJdye-0006fM-00 for idr@ietf.org; Fri, 30 Apr 2004 15:47:16 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Apr 2004 12:46:56 -0700 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3UJki0Q027821; Fri, 30 Apr 2004 12:46:45 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id MAA18552; Fri, 30 Apr 2004 12:46:44 -0700 In-Reply-To: <20040430044924.A7A82979C2@popserv2.redback.com> References: <20040430044924.A7A82979C2@popserv2.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen X-Mailer: Apple Mail (2.613) 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: Fri, 30 Apr 2004 14:46:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Enke, Please see inline. On Apr 29, 2004, at 11:49 PM, Enke Chen wrote: > Hi, Tom: > > Thanks for your comments, and sorry that I forgot to reply to your > original > message earlier. Please see my comments inline. > >> Message-Id: >> Cc: yakov@juniper.net, skh@nexthop.com >> From: Thomas Barron >> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt >> To: Enke Chen , idr@ietf.org >> >> Hi Enke, >> >> Attached is an email I sent to IDR that discusses some issues >> around >> your draft. I don't think I have seen a reply. >> >> I will add now that since that note I've discussed and thought a >> bit >> more about your argument in 5.2, and I think it is quite clear (and is >> indeed the received opinion nowadays) that the essential ingredient in >> these route-oscillation problems is the interaction of Route >> Reflectors >> and IGP costs. > > MED plays a major role as well. > Sure. >> Using sufficiently high IGP costs between clusters will suffice to >> stop >> the churn both in your scenario and in other scenarios that don't >> involve >> router-id. > > Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR). > I rather like the way the point is put there. > Re-configuring the IGP metric is certainly an option. However, > changing the > IGP metric typically has much larger impact on the network traffic > matrix, > and may not be desirable or feasible. > Hmmm. Maybe my thinking is just too pedestrian, but I don't myself see the design drivers for setting up RRs and RCs such that clusters don't "cluster" in terms of IGP metrics as well. >> Indeed, in your scenario if by chance >> the times of arrival correspond in the same order to that determined >> by >> the router-ids the churn is not avoided by your algorithm either (the >> proof is tedious, but intuitively: start the scenario with the same >> ranking of tie-breakers, just use time-of-arrival instead of >> router-id; >> then realize that this order gets preserved as the oscillation >> proceeds >> because the repeatedly advertised-and-withdrawn route will always be >> "newest" and correspond to the largest router id in the original >> scenario.) > > Do you have a specific example? I would like to understand better > whether > the algorithm is applicable to the example. > > Unlike the ADD-PATH approach (which is a complete solution), the > proposed > algorithm is effective only for a subset of route oscillations. > Well, if I'm right, it isn't always effective for this subset either. Consider the example in Fig. 3 where o R1, R2, R3 and R4 belong to one AS o R1 is a route reflector with R3 as its client. o R2 is a route reflector with R4 as its client. o External paths (a), (b) and (c) are as described in Fig. 4. +----+ 10 +----+ | R1 |--------------| R2 | +----+ +----+ | | | | | 5 | 20 | | | | +----+ +----+ | R3 | | R4 | +----+ +----+ / \ | / \ | (a) (b) (c) Figure 3 Path AS MED TimeofArrival a 1 0 2 b 2 20 1 c 2 10 5 Figure 4 Here is the oscillation: 1. R3 likes (b) over (a) (ToA) 2. R3 advertises (b) to R1 3. R1 hears (b, c) and prefers (c) (MED) 4. R1 advertises (c) to R3 5. R3 prefers (a) among (a, b, c) (MED + ToA) *NOTE* the arrival time of (c) is no longer 5, but it is some quantity >5. ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in favor of (c). 6. R3 advertises (a) to R1 7. R1 hears (a, c) and prefers (a) (IGP) 8. R1 advertises (a) to R2 9. R2 prefers (a) over (c) (lower IGP cost) 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 to R3 11. R3 prefers (b) over (a) since (c) is no longer available to disqualify (b) and ToA(b) < ToA(a) (Thanks to Nick Feamster, some time ago, for documenting these steps in a private email.) So, what we've done is keep everything the same in your example except that we've put ToA where you have Router ID. You make the point that "the BGP identifier of a route received from an external peer is just a random number" and that led me to think of the fact that the same can be said of the Time of Arrival. The interesting thing about your scenario is that the Time of Arrival of route (c) will change because it is withdrawn and readvertised, but since it is the highest that doesn't affect the order of the Times of Arrival so the formal parallelism with your case using BGP identifiers is preserved. >> >> But as I say in the attached, my argument is really with section >> 5.2, >> not with your overall proposal. There are implementations that >> provide >> a knob to do just what you are documenting and I agree that the BGP >> spec should provide for this option. >> >> Best regards, >> >> Tom Barron >> >> >>> From idr-admin@ietf.org Mon Nov 10 11:51:50 2003 >> From: Tom Barron >> To: idr@ietf.org >> Cc: Thomas P Barron >> Message-ID: <20031110174539.GA166@cfcentral.cisco.com> >> >> Enke, Srihari, et. al: >> >> I have some questions about draft-chen-bgp-avoid-transition-00.txt. >> I'm glad to see this draft since there are implementations out there >> using the route-selection algorithm this draft proposes, and since the >> proposed algorith is not what is documented in RFC1771 or in >> draft-ietf-idr-bgr4-22.txt section 9.1.2.2. >> >> First, is it the intent of this draft that the proposed algorithm >> should *replace* the algorithm currently documented, or just that >> it be added as an option? > > It is a backward-compatible extension to the base BGP spec.. Whether > it is ON or OFF, that is an implementation decision. (If that is the > intent of your question.) > Good. Yes, that is the intention of my question, and I suggest that you make this point explicitly in your draft. >> >> Second, while I think the claim in 5.1 that the proposed algorithm >> avoids an unnecessary best path transition is quite straightforward, >> there ought to be some discussion of concerns that have been expressed >> about the consequent lack of determinism in route selection. See >> for example section 7.1.4 of >> draft-ietf-idr-bgp4-experience-protocol-03.txt >> and appendix A of "Guidelines for Interdomain Traffic Engineering" by >> Feamster, Borkenhagen, and Rexford. I'm not personally convinced >> that this local indeterminism is a real big deal, but I do think it >> needs some discussion in your draft. > > As I recall, the only practical concern raised so far is the impact on > BGP testing script by the proposed algorithm, and the subject (impact > on the testing script) seems to be outside the scope of the document. > Please let me know if I have missed any other practical concerns. > Well, without getting into issues about whether Traffic Engineering is "practical" :-), I suggest that you might want to explicitly state that there may be circumstances in which an ISP is doing TE where this knob would be best left off. I am not myself aware of any other circumstances where the indeterminism that this knob introduces has any bad effects. >> >> Third, I found the argument at 5.2 to the effect that the proposed >> algorithm reduces route oscillation a bit unclear. Maybe just a bit >> more text is needed, but it seems to me that the really essential >> ingredient in your setup in figure 1 and figure 2 is not the router >> ID, but the high intracluster IGP metric. Indeed, though you cite >> RFC3345, that work focuses on IGP metrics, not router ID, as a >> critical factor for "type 1" oscillation scenarios (yours appears to >> be a type 1 variant.) If adjusting IGP metrics is sufficient to fix >> both your oscillation scenario and other type 1 scenarios, but >> shifting from Router ID selection to the proposed time-of-arrival >> algorithm is not sufficient for type 1 scenarios in general, then the >> contribution of the proposed algorithm to the route oscillation >> problem does not seem very decisive. On the other hand, if using the >> proposed time-of-arrival algorithm yields a general solution to >> oscillation problems, then this reader at least did not get that from >> the draft as currently written. >> > > We will work on adding more text to clarify. > >> I'm glad you folks wrote this draft. I hope it's clear that I'm >> not against your proposal, but rather want to address some gaps >> in my own understanding of the issues that surround it. >> > > Some of the gaps are with the text in the document :-) > We will work on improving it in the next version. > > Regards, > > -- Enke > Thanks, - Tom _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 17:12:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03324 for ; Fri, 30 Apr 2004 17:12:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfJB-0001pw-9d for idr-archive@ietf.org; Fri, 30 Apr 2004 17:12:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfI4-0001hL-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 17:11:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfHd-0001cM-00; Fri, 30 Apr 2004 17:10:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJef2-00024S-Pv; Fri, 30 Apr 2004 16:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFoj-0000WH-Sf for idr@optimus.ietf.org; Thu, 29 Apr 2004 13:59:25 -0400 Received: from dinara.foretec.com (dinaras-desktop.cnri.reston.va.us [10.27.16.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17149; Thu, 29 Apr 2004 13:59:18 -0400 (EDT) Message-Id: <6.1.0.6.2.20040429135711.02d606a0@odin> X-Sender: dinaras@odin X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: Pekka Savola , Yakov Rekhter From: Dinara Suleymanova Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Cc: Alex Zinin , , In-Reply-To: References: <200404201353.i3KDr1J39724@merlot.juniper.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: Thu, 29 Apr 2004 14:00:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hello, Could it be possible to UN-subscribe us/me (not sure what address was added on your subscription list) from your discussion list. Thanks a lot. Dinara Suleymanova At 12:35 PM 4/29/2004, Pekka Savola wrote: >On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > > 2) The definition of active route is bad. This fails in the > > > > situation where you need to export loopbacks/point-to-points to > > > > eBGP, but you have them in youro IGP. The specification does not > > > > consider them active (not used for forwarding), and they aren't > > > > exported. > > > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > > obviously this is no problem. Gargi Nalawade promised to submit > > > > text, but hasn't, and I think Yakov said something about being > > > > willing to incorporate that, but obviously hasn't. > > > > > > > > This was discussed at idr thread: > > > > > > > issue 11.2: active route, again > > > > > > > Otherwise, I think this was operationally good. > > > > > > Sue, Yakov, please check if the ball was dropped re this one. > > > > First of all, the consensus of the WG (as documented in > > draft-ietf-idr-bgp-issues) is to have the following text: > > > > In the context of this document we assume that a BGP speaker > > advertises to its peers only those routes that it itself uses (in > > this context a BGP speaker is said to "use" a BGP route if it is the > > most preferred BGP route and is used in forwarding). All other cases > > are outside the scope of this document. > > > > While this text does not cover the case described by Pekka, it does > > not preclude it either - handling the case described by Pekka > > is just outside the scope of the spec. > > > > With this in mind I suggest that the case described by Pekka > > should be covered in a separate Internet Draft. > >I think this is operationally a rather common (or even very common) >scenario, and it would seem very disadvantageous not to tackle it in >this specification. Further, there's major deployment of it (maybe >even multi-vendor -- probably) so there is considerable proof that it >works. > >It should be the default behaviour of BGP as that's which makes the >most sense, operationally. "BGP route is ... used by forwarding" does >not sufficiently cover the fact that people do use IGPs and there's >often overlap with IGP and BGP :). > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 17:26:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04991 for ; Fri, 30 Apr 2004 17:26:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfKO-000164-Gj for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 17:13:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULDmw9004214 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 17:13:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf6a-0004VD-Ka for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 16:59: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 QAA02663 for ; Fri, 30 Apr 2004 16:59:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJf6Y-0000b9-Gk for idr-web-archive@ietf.org; Fri, 30 Apr 2004 16:59:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJf5k-0000VI-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 16:58:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJf51-0000Oq-00; Fri, 30 Apr 2004 16:57:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJf4z-0001u6-9v; Fri, 30 Apr 2004 16:57:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe7n-0003TS-17; Fri, 30 Apr 2004 15:56:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe0Y-0000X3-BW for idr@optimus.ietf.org; Fri, 30 Apr 2004 15:49: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 PAA26771 for ; Fri, 30 Apr 2004 15:49:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJe0W-0006uv-Rb for idr@ietf.org; Fri, 30 Apr 2004 15:49:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdzY-0006qR-00 for idr@ietf.org; Fri, 30 Apr 2004 15:48:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BJdye-0006fM-00 for idr@ietf.org; Fri, 30 Apr 2004 15:47:16 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Apr 2004 12:46:56 -0700 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3UJki0Q027821; Fri, 30 Apr 2004 12:46:45 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id MAA18552; Fri, 30 Apr 2004 12:46:44 -0700 In-Reply-To: <20040430044924.A7A82979C2@popserv2.redback.com> References: <20040430044924.A7A82979C2@popserv2.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen X-Mailer: Apple Mail (2.613) 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: Fri, 30 Apr 2004 14:46:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Enke, Please see inline. On Apr 29, 2004, at 11:49 PM, Enke Chen wrote: > Hi, Tom: > > Thanks for your comments, and sorry that I forgot to reply to your > original > message earlier. Please see my comments inline. > >> Message-Id: >> Cc: yakov@juniper.net, skh@nexthop.com >> From: Thomas Barron >> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt >> To: Enke Chen , idr@ietf.org >> >> Hi Enke, >> >> Attached is an email I sent to IDR that discusses some issues >> around >> your draft. I don't think I have seen a reply. >> >> I will add now that since that note I've discussed and thought a >> bit >> more about your argument in 5.2, and I think it is quite clear (and is >> indeed the received opinion nowadays) that the essential ingredient in >> these route-oscillation problems is the interaction of Route >> Reflectors >> and IGP costs. > > MED plays a major role as well. > Sure. >> Using sufficiently high IGP costs between clusters will suffice to >> stop >> the churn both in your scenario and in other scenarios that don't >> involve >> router-id. > > Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR). > I rather like the way the point is put there. > Re-configuring the IGP metric is certainly an option. However, > changing the > IGP metric typically has much larger impact on the network traffic > matrix, > and may not be desirable or feasible. > Hmmm. Maybe my thinking is just too pedestrian, but I don't myself see the design drivers for setting up RRs and RCs such that clusters don't "cluster" in terms of IGP metrics as well. >> Indeed, in your scenario if by chance >> the times of arrival correspond in the same order to that determined >> by >> the router-ids the churn is not avoided by your algorithm either (the >> proof is tedious, but intuitively: start the scenario with the same >> ranking of tie-breakers, just use time-of-arrival instead of >> router-id; >> then realize that this order gets preserved as the oscillation >> proceeds >> because the repeatedly advertised-and-withdrawn route will always be >> "newest" and correspond to the largest router id in the original >> scenario.) > > Do you have a specific example? I would like to understand better > whether > the algorithm is applicable to the example. > > Unlike the ADD-PATH approach (which is a complete solution), the > proposed > algorithm is effective only for a subset of route oscillations. > Well, if I'm right, it isn't always effective for this subset either. Consider the example in Fig. 3 where o R1, R2, R3 and R4 belong to one AS o R1 is a route reflector with R3 as its client. o R2 is a route reflector with R4 as its client. o External paths (a), (b) and (c) are as described in Fig. 4. +----+ 10 +----+ | R1 |--------------| R2 | +----+ +----+ | | | | | 5 | 20 | | | | +----+ +----+ | R3 | | R4 | +----+ +----+ / \ | / \ | (a) (b) (c) Figure 3 Path AS MED TimeofArrival a 1 0 2 b 2 20 1 c 2 10 5 Figure 4 Here is the oscillation: 1. R3 likes (b) over (a) (ToA) 2. R3 advertises (b) to R1 3. R1 hears (b, c) and prefers (c) (MED) 4. R1 advertises (c) to R3 5. R3 prefers (a) among (a, b, c) (MED + ToA) *NOTE* the arrival time of (c) is no longer 5, but it is some quantity >5. ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in favor of (c). 6. R3 advertises (a) to R1 7. R1 hears (a, c) and prefers (a) (IGP) 8. R1 advertises (a) to R2 9. R2 prefers (a) over (c) (lower IGP cost) 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 to R3 11. R3 prefers (b) over (a) since (c) is no longer available to disqualify (b) and ToA(b) < ToA(a) (Thanks to Nick Feamster, some time ago, for documenting these steps in a private email.) So, what we've done is keep everything the same in your example except that we've put ToA where you have Router ID. You make the point that "the BGP identifier of a route received from an external peer is just a random number" and that led me to think of the fact that the same can be said of the Time of Arrival. The interesting thing about your scenario is that the Time of Arrival of route (c) will change because it is withdrawn and readvertised, but since it is the highest that doesn't affect the order of the Times of Arrival so the formal parallelism with your case using BGP identifiers is preserved. >> >> But as I say in the attached, my argument is really with section >> 5.2, >> not with your overall proposal. There are implementations that >> provide >> a knob to do just what you are documenting and I agree that the BGP >> spec should provide for this option. >> >> Best regards, >> >> Tom Barron >> >> >>> From idr-admin@ietf.org Mon Nov 10 11:51:50 2003 >> From: Tom Barron >> To: idr@ietf.org >> Cc: Thomas P Barron >> Message-ID: <20031110174539.GA166@cfcentral.cisco.com> >> >> Enke, Srihari, et. al: >> >> I have some questions about draft-chen-bgp-avoid-transition-00.txt. >> I'm glad to see this draft since there are implementations out there >> using the route-selection algorithm this draft proposes, and since the >> proposed algorith is not what is documented in RFC1771 or in >> draft-ietf-idr-bgr4-22.txt section 9.1.2.2. >> >> First, is it the intent of this draft that the proposed algorithm >> should *replace* the algorithm currently documented, or just that >> it be added as an option? > > It is a backward-compatible extension to the base BGP spec.. Whether > it is ON or OFF, that is an implementation decision. (If that is the > intent of your question.) > Good. Yes, that is the intention of my question, and I suggest that you make this point explicitly in your draft. >> >> Second, while I think the claim in 5.1 that the proposed algorithm >> avoids an unnecessary best path transition is quite straightforward, >> there ought to be some discussion of concerns that have been expressed >> about the consequent lack of determinism in route selection. See >> for example section 7.1.4 of >> draft-ietf-idr-bgp4-experience-protocol-03.txt >> and appendix A of "Guidelines for Interdomain Traffic Engineering" by >> Feamster, Borkenhagen, and Rexford. I'm not personally convinced >> that this local indeterminism is a real big deal, but I do think it >> needs some discussion in your draft. > > As I recall, the only practical concern raised so far is the impact on > BGP testing script by the proposed algorithm, and the subject (impact > on the testing script) seems to be outside the scope of the document. > Please let me know if I have missed any other practical concerns. > Well, without getting into issues about whether Traffic Engineering is "practical" :-), I suggest that you might want to explicitly state that there may be circumstances in which an ISP is doing TE where this knob would be best left off. I am not myself aware of any other circumstances where the indeterminism that this knob introduces has any bad effects. >> >> Third, I found the argument at 5.2 to the effect that the proposed >> algorithm reduces route oscillation a bit unclear. Maybe just a bit >> more text is needed, but it seems to me that the really essential >> ingredient in your setup in figure 1 and figure 2 is not the router >> ID, but the high intracluster IGP metric. Indeed, though you cite >> RFC3345, that work focuses on IGP metrics, not router ID, as a >> critical factor for "type 1" oscillation scenarios (yours appears to >> be a type 1 variant.) If adjusting IGP metrics is sufficient to fix >> both your oscillation scenario and other type 1 scenarios, but >> shifting from Router ID selection to the proposed time-of-arrival >> algorithm is not sufficient for type 1 scenarios in general, then the >> contribution of the proposed algorithm to the route oscillation >> problem does not seem very decisive. On the other hand, if using the >> proposed time-of-arrival algorithm yields a general solution to >> oscillation problems, then this reader at least did not get that from >> the draft as currently written. >> > > We will work on adding more text to clarify. > >> I'm glad you folks wrote this draft. I hope it's clear that I'm >> not against your proposal, but rather want to address some gaps >> in my own understanding of the issues that surround it. >> > > Some of the gaps are with the text in the document :-) > We will work on improving it in the next version. > > Regards, > > -- Enke > Thanks, - Tom _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 17:35:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05575 for ; Fri, 30 Apr 2004 17:35:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfVu-0004T8-8w for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 17:25:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULPgI7017174 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 17:25:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfJG-00006S-SP for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:12:38 -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 RAA03350 for ; Fri, 30 Apr 2004 17:12:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfJE-0001qT-ON for idr-web-archive@ietf.org; Fri, 30 Apr 2004 17:12:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfI5-0001hh-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 17:11:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfHd-0001cM-00; Fri, 30 Apr 2004 17:10:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJef2-00024S-Pv; Fri, 30 Apr 2004 16:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFoj-0000WH-Sf for idr@optimus.ietf.org; Thu, 29 Apr 2004 13:59:25 -0400 Received: from dinara.foretec.com (dinaras-desktop.cnri.reston.va.us [10.27.16.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17149; Thu, 29 Apr 2004 13:59:18 -0400 (EDT) Message-Id: <6.1.0.6.2.20040429135711.02d606a0@odin> X-Sender: dinaras@odin X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: Pekka Savola , Yakov Rekhter From: Dinara Suleymanova Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Cc: Alex Zinin , , In-Reply-To: References: <200404201353.i3KDr1J39724@merlot.juniper.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: Thu, 29 Apr 2004 14:00:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hello, Could it be possible to UN-subscribe us/me (not sure what address was added on your subscription list) from your discussion list. Thanks a lot. Dinara Suleymanova At 12:35 PM 4/29/2004, Pekka Savola wrote: >On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > > 2) The definition of active route is bad. This fails in the > > > > situation where you need to export loopbacks/point-to-points to > > > > eBGP, but you have them in youro IGP. The specification does not > > > > consider them active (not used for forwarding), and they aren't > > > > exported. > > > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > > obviously this is no problem. Gargi Nalawade promised to submit > > > > text, but hasn't, and I think Yakov said something about being > > > > willing to incorporate that, but obviously hasn't. > > > > > > > > This was discussed at idr thread: > > > > > > > issue 11.2: active route, again > > > > > > > Otherwise, I think this was operationally good. > > > > > > Sue, Yakov, please check if the ball was dropped re this one. > > > > First of all, the consensus of the WG (as documented in > > draft-ietf-idr-bgp-issues) is to have the following text: > > > > In the context of this document we assume that a BGP speaker > > advertises to its peers only those routes that it itself uses (in > > this context a BGP speaker is said to "use" a BGP route if it is the > > most preferred BGP route and is used in forwarding). All other cases > > are outside the scope of this document. > > > > While this text does not cover the case described by Pekka, it does > > not preclude it either - handling the case described by Pekka > > is just outside the scope of the spec. > > > > With this in mind I suggest that the case described by Pekka > > should be covered in a separate Internet Draft. > >I think this is operationally a rather common (or even very common) >scenario, and it would seem very disadvantageous not to tackle it in >this specification. Further, there's major deployment of it (maybe >even multi-vendor -- probably) so there is considerable proof that it >works. > >It should be the default behaviour of BGP as that's which makes the >most sense, operationally. "BGP route is ... used by forwarding" does >not sufficiently cover the fact that people do use IGPs and there's >often overlap with IGP and BGP :). > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 17:36:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05611 for ; Fri, 30 Apr 2004 17:36:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfgG-0005Cx-Lh for idr-archive@ietf.org; Fri, 30 Apr 2004 17:36:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJffG-00055o-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 17:35:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfer-000510-00; Fri, 30 Apr 2004 17:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfUM-0004BH-6X; Fri, 30 Apr 2004 17:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfEA-000660-3x for idr@optimus.ietf.org; Fri, 30 Apr 2004 17:07: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 RAA03107 for ; Fri, 30 Apr 2004 17:07:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfE7-0001LD-Tk for idr@ietf.org; Fri, 30 Apr 2004 17:07:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfDC-0001G2-00 for idr@ietf.org; Fri, 30 Apr 2004 17:06:23 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJfCH-000177-00 for idr@ietf.org; Fri, 30 Apr 2004 17:05:26 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 475682D4863 for ; Fri, 30 Apr 2004 17:04:56 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 49519-01-25 for ; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CD6B82D484A for ; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3UL4ii24497 for idr@ietf.org; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document Message-ID: <20040430170444.K23652@nexthop.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net>; from yakov@juniper.net on Mon, Apr 26, 2004 at 08:01:36AM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 17:04:44 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Apr 26, 2004 at 08:01:36AM -0700, Yakov Rekhter wrote: > Please comment on the attached. The deadline for comments is > May 10. I would urge that this document not be accepted. I think that a multi-session BGP is a better solution, perhaps with a graceful failover mechanism. I would offer many of the same reasons that Pedro did, specifically the inability to deal with a corrupt TCP stream. I believe that most of the shutdown reasons that we cared about have been addressed in the current cease subcode document undergoing last call. The prefix-limit issue is working itself out in other documents. One note on BGP multi-session with regards to operational issues: The BGP v2MIB includes the ability to montior multiple peering sessions to a single peer across the same src/dst addresses. > Yakov. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 17:48:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06798 for ; Fri, 30 Apr 2004 17:48: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 1BJfnJ-0002E8-Ul for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 17:43:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULhfoI008550 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 17:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfgK-00086V-E7 for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:36:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05637 for ; Fri, 30 Apr 2004 17:36:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfgI-0005D7-02 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 17:36:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJffH-000562-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 17:35:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfer-000510-00; Fri, 30 Apr 2004 17:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfUM-0004BH-6X; Fri, 30 Apr 2004 17:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfEA-000660-3x for idr@optimus.ietf.org; Fri, 30 Apr 2004 17:07: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 RAA03107 for ; Fri, 30 Apr 2004 17:07:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfE7-0001LD-Tk for idr@ietf.org; Fri, 30 Apr 2004 17:07:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfDC-0001G2-00 for idr@ietf.org; Fri, 30 Apr 2004 17:06:23 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJfCH-000177-00 for idr@ietf.org; Fri, 30 Apr 2004 17:05:26 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 475682D4863 for ; Fri, 30 Apr 2004 17:04:56 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 49519-01-25 for ; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CD6B82D484A for ; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3UL4ii24497 for idr@ietf.org; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document Message-ID: <20040430170444.K23652@nexthop.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net>; from yakov@juniper.net on Mon, Apr 26, 2004 at 08:01:36AM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 17:04:44 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Apr 26, 2004 at 08:01:36AM -0700, Yakov Rekhter wrote: > Please comment on the attached. The deadline for comments is > May 10. I would urge that this document not be accepted. I think that a multi-session BGP is a better solution, perhaps with a graceful failover mechanism. I would offer many of the same reasons that Pedro did, specifically the inability to deal with a corrupt TCP stream. I believe that most of the shutdown reasons that we cared about have been addressed in the current cease subcode document undergoing last call. The prefix-limit issue is working itself out in other documents. One note on BGP multi-session with regards to operational issues: The BGP v2MIB includes the ability to montior multiple peering sessions to a single peer across the same src/dst addresses. > Yakov. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 18:31:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10063 for ; Fri, 30 Apr 2004 18:31:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgXS-00031j-5l for idr-archive@ietf.org; Fri, 30 Apr 2004 18:31:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgWR-0002vS-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 18:30:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgVq-0002rT-00; Fri, 30 Apr 2004 18:29:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgQN-00016q-8R; Fri, 30 Apr 2004 18:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgLp-00085j-Eq for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09321 for ; Fri, 30 Apr 2004 18:19:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgLm-0001q1-IF for idr@ietf.org; Fri, 30 Apr 2004 18:19:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgKq-0001lf-00 for idr@ietf.org; Fri, 30 Apr 2004 18:18:21 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJgK1-0001hX-00 for idr@ietf.org; Fri, 30 Apr 2004 18:17:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2DE8B13F305; Fri, 30 Apr 2004 15:17:23 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25174-02; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id AD17313F302; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 27D35979C2; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) To: Thomas Barron Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: Message from Thomas Barron of "Fri, 30 Apr 2004 14:46:43 CDT." <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> From: Enke Chen Message-Id: <20040430221722.27D35979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:17:21 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Tom: Please see inline. > Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> > Content-Transfer-Encoding: 7bit > Cc: idr@ietf.org > From: Thomas Barron > Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt > Date: Fri, 30 Apr 2004 14:46:43 -0500 > To: Enke Chen > [snip] > Well, if I'm right, it isn't always effective for this subset either. > > Consider the example in Fig. 3 where > > o R1, R2, R3 and R4 belong to one AS > o R1 is a route reflector with R3 as its client. > o R2 is a route reflector with R4 as its client. > o External paths (a), (b) and (c) are as described in Fig. 4. > > > +----+ 10 +----+ > | R1 |--------------| R2 | > +----+ +----+ > | | > | | > | 5 | 20 > | | > | | > +----+ +----+ > | R3 | | R4 | > +----+ +----+ > / \ | > / \ | > (a) (b) (c) > > Figure 3 > > > Path AS MED TimeofArrival > a 1 0 2 > b 2 20 1 > c 2 10 5 > > Figure 4 > > Here is the oscillation: > > 1. R3 likes (b) over (a) (ToA) > 2. R3 advertises (b) to R1 > 3. R1 hears (b, c) and prefers (c) (MED) > 4. R1 advertises (c) to R3 > 5. R3 prefers (a) among (a, b, c) (MED + ToA) > *NOTE* the arrival time of (c) is no longer 5, but it is some > quantity >5. > ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in > favor of (c). > 6. R3 advertises (a) to R1 > 7. R1 hears (a, c) and prefers (a) (IGP) > 8. R1 advertises (a) to R2 > 9. R2 prefers (a) over (c) (lower IGP cost) > 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 > to R3 > 11. R3 prefers (b) over (a) since (c) is no longer available to > disqualify (b) and > ToA(b) < ToA(a) I see where your confusion was. The proposed algorithm in Sect. 4 of the draft does not really care about ToA ("Time of Arrival"). It just says that "Do not switch the best path from one EBGP path to another EBGP path when the comparison comes down to the route-id. So, in Step 11, if you follow the proposed algorithm, (a) will remain as the best path on R3, and the churn will stop. I will need to think about other comments of yours, and try to clarify the text in the next version. Thanks. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 18:45:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10841 for ; Fri, 30 Apr 2004 18:45:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgkz-0004UE-U5 for idr-archive@ietf.org; Fri, 30 Apr 2004 18:45:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgk5-0004PD-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 18:44:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgja-0004KW-00; Fri, 30 Apr 2004 18:43:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgft-0003jh-Uj; Fri, 30 Apr 2004 18:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgUl-0001ee-81 for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:28:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09893 for ; Fri, 30 Apr 2004 18:28:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgUi-0002m2-9F for idr@ietf.org; Fri, 30 Apr 2004 18:28:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgTi-0002fA-00 for idr@ietf.org; Fri, 30 Apr 2004 18:27:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJgSm-0002TN-00 for idr@ietf.org; Fri, 30 Apr 2004 18:26:32 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 2EEA62D4863; Fri, 30 Apr 2004 18:25:58 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51072-01-47; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7E27B2D484A; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3UMPkN24616; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) From: Jeffrey Haas To: Thomas Barron Cc: Enke Chen , idr@ietf.org Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt Message-ID: <20040430182545.L23652@nexthop.com> References: <20040430044924.A7A82979C2@popserv2.redback.com> <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com>; from tbarron@cisco.com on Fri, Apr 30, 2004 at 02:46:43PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 18:25:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Apr 30, 2004 at 02:46:43PM -0500, Thomas Barron wrote: > I am not myself aware of any other circumstances where the > indeterminism that this knob introduces has any bad effects. Or existing implementations of this knob that already do this. :-) Speaking as a former network operator of a tier-3 ISP, it took us a while to understand why otherwise very stable paths would all of a sudden take a sharp turn. This was typically noticed when the new stable path was poor for some reason. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 18:46:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10960 for ; Fri, 30 Apr 2004 18:46: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 1BJggo-00040w-Uq for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:41:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UMf2wR015430 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgXY-0001zL-DG for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:31:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10086 for ; Fri, 30 Apr 2004 18:31:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgXV-000326-EA for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:31:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgWT-0002vj-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:30:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgVq-0002rT-00; Fri, 30 Apr 2004 18:29:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgQN-00016q-8R; Fri, 30 Apr 2004 18:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgLp-00085j-Eq for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09321 for ; Fri, 30 Apr 2004 18:19:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgLm-0001q1-IF for idr@ietf.org; Fri, 30 Apr 2004 18:19:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgKq-0001lf-00 for idr@ietf.org; Fri, 30 Apr 2004 18:18:21 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJgK1-0001hX-00 for idr@ietf.org; Fri, 30 Apr 2004 18:17:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2DE8B13F305; Fri, 30 Apr 2004 15:17:23 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25174-02; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id AD17313F302; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 27D35979C2; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) To: Thomas Barron Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: Message from Thomas Barron of "Fri, 30 Apr 2004 14:46:43 CDT." <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> From: Enke Chen Message-Id: <20040430221722.27D35979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:17:21 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Tom: Please see inline. > Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> > Content-Transfer-Encoding: 7bit > Cc: idr@ietf.org > From: Thomas Barron > Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt > Date: Fri, 30 Apr 2004 14:46:43 -0500 > To: Enke Chen > [snip] > Well, if I'm right, it isn't always effective for this subset either. > > Consider the example in Fig. 3 where > > o R1, R2, R3 and R4 belong to one AS > o R1 is a route reflector with R3 as its client. > o R2 is a route reflector with R4 as its client. > o External paths (a), (b) and (c) are as described in Fig. 4. > > > +----+ 10 +----+ > | R1 |--------------| R2 | > +----+ +----+ > | | > | | > | 5 | 20 > | | > | | > +----+ +----+ > | R3 | | R4 | > +----+ +----+ > / \ | > / \ | > (a) (b) (c) > > Figure 3 > > > Path AS MED TimeofArrival > a 1 0 2 > b 2 20 1 > c 2 10 5 > > Figure 4 > > Here is the oscillation: > > 1. R3 likes (b) over (a) (ToA) > 2. R3 advertises (b) to R1 > 3. R1 hears (b, c) and prefers (c) (MED) > 4. R1 advertises (c) to R3 > 5. R3 prefers (a) among (a, b, c) (MED + ToA) > *NOTE* the arrival time of (c) is no longer 5, but it is some > quantity >5. > ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in > favor of (c). > 6. R3 advertises (a) to R1 > 7. R1 hears (a, c) and prefers (a) (IGP) > 8. R1 advertises (a) to R2 > 9. R2 prefers (a) over (c) (lower IGP cost) > 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 > to R3 > 11. R3 prefers (b) over (a) since (c) is no longer available to > disqualify (b) and > ToA(b) < ToA(a) I see where your confusion was. The proposed algorithm in Sect. 4 of the draft does not really care about ToA ("Time of Arrival"). It just says that "Do not switch the best path from one EBGP path to another EBGP path when the comparison comes down to the route-id. So, in Step 11, if you follow the proposed algorithm, (a) will remain as the best path on R3, and the churn will stop. I will need to think about other comments of yours, and try to clarify the text in the next version. Thanks. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 18:52:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11227 for ; Fri, 30 Apr 2004 18:52:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgs0-0005C2-4y for idr-archive@ietf.org; Fri, 30 Apr 2004 18:52:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgqz-00054M-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 18:51:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgqh-0004xk-00; Fri, 30 Apr 2004 18:51:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJghr-0004JW-HR; Fri, 30 Apr 2004 18:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgfF-0003b9-HG for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10535 for ; Fri, 30 Apr 2004 18:39:21 -0400 (EDT) From: jenny@redback.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgfC-0003pn-Ed for idr@ietf.org; Fri, 30 Apr 2004 18:39:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgeK-0003kR-00 for idr@ietf.org; Fri, 30 Apr 2004 18:38:29 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJgdR-0003fo-00 for idr@ietf.org; Fri, 30 Apr 2004 18:37:33 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id ECB36BF7F03; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28235-02; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 7C3B6BF7F02; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: (from jenny@localhost) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id PAA08889; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Message-Id: <200404302237.PAA08889@redback.com> Subject: Re: Yakov Rekhter: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document To: yakov@juniper.net Cc: jenny@redback.com, idr@ietf.org In-Reply-To: <20040430222422.E977215D3C3@popserv1.redback.com> from "Enke Chen" at Apr 30, 2004 03:24:21 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com 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: Fri, 30 Apr 2004 15:37:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I vote yes to have it be accepted as an IDR WG document. thanks, jenny > > > ------- Forwarded Message > > Message-Id: <200404301721.i3UHLjJ28638@merlot.juniper.net> > To: idr@ietf.org > From: Yakov Rekhter > Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document > Date: Fri, 30 Apr 2004 10:21:45 -0700 > > Folks > > We receive a request to accept draft-chen-bgp-avoid-transition-01.txt > as an IDR WG document. Please comment to the list. The deadline > for comments is May 14, 2004. > > Yakov. > - ------- Forwarded Message > > Date: Wed, 28 Apr 2004 10:13:29 -0700 > From: Enke Chen > To: yakov@juniper.net, skh@nexthop.com > cc: idr@ietf.org > Subject: draft-chen-bgp-avoid-transition-01.txt > > Hi, Yakov and Sue: > > I would like to request that the draft > be accepted as an IDR WG document. The draft was presented previosuly at an > IDR meeting. The algorithm described in the draft has been deployed for several > years. > > Thanks. -- Enke > > - - ------- Forwarded Message > > Message-Id: <200401201504.KAA02287@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt > Date: Tue, 20 Jan 2004 10:04:35 -0500 > > - - - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Avoid BGP Best Path Transition from One External to A > nother > Author(s) : E. Chen, S. Sangli > Filename : draft-chen-bgp-avoid-transition-01.txt > Pages : 5 > Date : 2004-1-19 > > In this document we propose an algorithm that would help improve the > overall network stability by avoiding BGP best path transition from > one external to another (under certain conditions) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt > > > - - ------- End of Forwarded Message > > > - ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 18:53:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11259 for ; Fri, 30 Apr 2004 18:53: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 1BJgrK-0006cY-IQ for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:51:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UMpsp4025445 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:51:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgl5-00053h-9H for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:45:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10867 for ; Fri, 30 Apr 2004 18:45:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgl2-0004UZ-6z for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:45:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgk7-0004PU-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:44:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgja-0004KW-00; Fri, 30 Apr 2004 18:43:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgft-0003jh-Uj; Fri, 30 Apr 2004 18:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgUl-0001ee-81 for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:28:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09893 for ; Fri, 30 Apr 2004 18:28:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgUi-0002m2-9F for idr@ietf.org; Fri, 30 Apr 2004 18:28:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgTi-0002fA-00 for idr@ietf.org; Fri, 30 Apr 2004 18:27:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJgSm-0002TN-00 for idr@ietf.org; Fri, 30 Apr 2004 18:26:32 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 2EEA62D4863; Fri, 30 Apr 2004 18:25:58 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51072-01-47; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7E27B2D484A; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3UMPkN24616; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) From: Jeffrey Haas To: Thomas Barron Cc: Enke Chen , idr@ietf.org Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt Message-ID: <20040430182545.L23652@nexthop.com> References: <20040430044924.A7A82979C2@popserv2.redback.com> <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com>; from tbarron@cisco.com on Fri, Apr 30, 2004 at 02:46:43PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 18:25:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Apr 30, 2004 at 02:46:43PM -0500, Thomas Barron wrote: > I am not myself aware of any other circumstances where the > indeterminism that this knob introduces has any bad effects. Or existing implementations of this knob that already do this. :-) Speaking as a former network operator of a tier-3 ISP, it took us a while to understand why otherwise very stable paths would all of a sudden take a sharp turn. This was typically noticed when the new stable path was poor for some reason. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 18:56:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11503 for ; Fri, 30 Apr 2004 18:56:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgvm-0005gO-V8 for idr-archive@ietf.org; Fri, 30 Apr 2004 18:56:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJguv-0005Zq-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 18:55:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgu8-0005TT-00; Fri, 30 Apr 2004 18:54:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgrR-0006eL-0R; Fri, 30 Apr 2004 18:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgjE-0004aO-89 for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:43: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 SAA10781 for ; Fri, 30 Apr 2004 18:43:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgjB-0004Jf-4B for idr@ietf.org; Fri, 30 Apr 2004 18:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgiF-0004DU-00 for idr@ietf.org; Fri, 30 Apr 2004 18:42:32 -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 1BJghQ-00040m-00 for idr@ietf.org; Fri, 30 Apr 2004 18:41:40 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2004 14:54:45 +0000 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UMf9W9024449; Fri, 30 Apr 2004 15:41:09 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id PAA12897; Fri, 30 Apr 2004 15:41:08 -0700 In-Reply-To: <20040430221722.27D35979C2@popserv2.redback.com> References: <20040430221722.27D35979C2@popserv2.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <787AD86D-9AF7-11D8-BA2C-00039375647A@cisco.com> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen X-Mailer: Apple Mail (2.613) 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: Fri, 30 Apr 2004 17:41:07 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Enke, Thanks for clarifying. I'm cool with this :-) - Tom On Apr 30, 2004, at 5:17 PM, Enke Chen wrote: > Hi, Tom: > > Please see inline. > >> Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> >> Content-Transfer-Encoding: 7bit >> Cc: idr@ietf.org >> From: Thomas Barron >> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt >> Date: Fri, 30 Apr 2004 14:46:43 -0500 >> To: Enke Chen >> > > [snip] > >> Well, if I'm right, it isn't always effective for this subset either. >> >> Consider the example in Fig. 3 where >> >> o R1, R2, R3 and R4 belong to one AS >> o R1 is a route reflector with R3 as its client. >> o R2 is a route reflector with R4 as its client. >> o External paths (a), (b) and (c) are as described in Fig. 4. >> >> >> +----+ 10 +----+ >> | R1 |--------------| R2 | >> +----+ +----+ >> | | >> | | >> | 5 | 20 >> | | >> | | >> +----+ +----+ >> | R3 | | R4 | >> +----+ +----+ >> / \ | >> / \ | >> (a) (b) (c) >> >> Figure 3 >> >> >> Path AS MED TimeofArrival >> a 1 0 2 >> b 2 20 1 >> c 2 10 5 >> >> Figure 4 >> >> Here is the oscillation: >> >> 1. R3 likes (b) over (a) (ToA) >> 2. R3 advertises (b) to R1 >> 3. R1 hears (b, c) and prefers (c) (MED) >> 4. R1 advertises (c) to R3 >> 5. R3 prefers (a) among (a, b, c) (MED + ToA) >> *NOTE* the arrival time of (c) is no longer 5, but it is some >> quantity >5. >> ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in >> favor of (c). >> 6. R3 advertises (a) to R1 >> 7. R1 hears (a, c) and prefers (a) (IGP) >> 8. R1 advertises (a) to R2 >> 9. R2 prefers (a) over (c) (lower IGP cost) >> 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 >> to R3 >> 11. R3 prefers (b) over (a) since (c) is no longer available to >> disqualify (b) and >> ToA(b) < ToA(a) > > > I see where your confusion was. The proposed algorithm in Sect. 4 of > the > draft does not really care about ToA ("Time of Arrival"). It just says > that "Do not switch the best path from one EBGP path to another EBGP > path when the comparison comes down to the route-id. > > So, in Step 11, if you follow the proposed algorithm, (a) will remain > as the best path on R3, and the churn will stop. > > I will need to think about other comments of yours, and try to clarify > the text in the next version. > > Thanks. -- Enke > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 19:06:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11976 for ; Fri, 30 Apr 2004 19:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgxx-0007tw-12 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:58:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UMwiVb030367 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgs4-0006mK-FW for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:52: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 SAA11253 for ; Fri, 30 Apr 2004 18:52:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgs1-0005CC-E2 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:52:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgr1-00054a-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:51:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgqh-0004xk-00; Fri, 30 Apr 2004 18:51:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJghr-0004JW-HR; Fri, 30 Apr 2004 18:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgfF-0003b9-HG for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10535 for ; Fri, 30 Apr 2004 18:39:21 -0400 (EDT) From: jenny@redback.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgfC-0003pn-Ed for idr@ietf.org; Fri, 30 Apr 2004 18:39:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgeK-0003kR-00 for idr@ietf.org; Fri, 30 Apr 2004 18:38:29 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJgdR-0003fo-00 for idr@ietf.org; Fri, 30 Apr 2004 18:37:33 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id ECB36BF7F03; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28235-02; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 7C3B6BF7F02; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: (from jenny@localhost) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id PAA08889; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Message-Id: <200404302237.PAA08889@redback.com> Subject: Re: Yakov Rekhter: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document To: yakov@juniper.net Cc: jenny@redback.com, idr@ietf.org In-Reply-To: <20040430222422.E977215D3C3@popserv1.redback.com> from "Enke Chen" at Apr 30, 2004 03:24:21 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com 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: Fri, 30 Apr 2004 15:37:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I vote yes to have it be accepted as an IDR WG document. thanks, jenny > > > ------- Forwarded Message > > Message-Id: <200404301721.i3UHLjJ28638@merlot.juniper.net> > To: idr@ietf.org > From: Yakov Rekhter > Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document > Date: Fri, 30 Apr 2004 10:21:45 -0700 > > Folks > > We receive a request to accept draft-chen-bgp-avoid-transition-01.txt > as an IDR WG document. Please comment to the list. The deadline > for comments is May 14, 2004. > > Yakov. > - ------- Forwarded Message > > Date: Wed, 28 Apr 2004 10:13:29 -0700 > From: Enke Chen > To: yakov@juniper.net, skh@nexthop.com > cc: idr@ietf.org > Subject: draft-chen-bgp-avoid-transition-01.txt > > Hi, Yakov and Sue: > > I would like to request that the draft > be accepted as an IDR WG document. The draft was presented previosuly at an > IDR meeting. The algorithm described in the draft has been deployed for several > years. > > Thanks. -- Enke > > - - ------- Forwarded Message > > Message-Id: <200401201504.KAA02287@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt > Date: Tue, 20 Jan 2004 10:04:35 -0500 > > - - - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Avoid BGP Best Path Transition from One External to A > nother > Author(s) : E. Chen, S. Sangli > Filename : draft-chen-bgp-avoid-transition-01.txt > Pages : 5 > Date : 2004-1-19 > > In this document we propose an algorithm that would help improve the > overall network stability by avoiding BGP best path transition from > one external to another (under certain conditions) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt > > > - - ------- End of Forwarded Message > > > - ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 19:06:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12011 for ; Fri, 30 Apr 2004 19:06:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgyA-0007xk-RO for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:58:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UMwwNi030603 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 18:58:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgvr-0007L7-IA for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:56:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11529 for ; Fri, 30 Apr 2004 18:56:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgvo-0005gY-Ab for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:56:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgux-0005a4-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 18:55:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgu8-0005TT-00; Fri, 30 Apr 2004 18:54:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgrR-0006eL-0R; Fri, 30 Apr 2004 18:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgjE-0004aO-89 for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:43: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 SAA10781 for ; Fri, 30 Apr 2004 18:43:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgjB-0004Jf-4B for idr@ietf.org; Fri, 30 Apr 2004 18:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgiF-0004DU-00 for idr@ietf.org; Fri, 30 Apr 2004 18:42:32 -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 1BJghQ-00040m-00 for idr@ietf.org; Fri, 30 Apr 2004 18:41:40 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2004 14:54:45 +0000 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UMf9W9024449; Fri, 30 Apr 2004 15:41:09 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id PAA12897; Fri, 30 Apr 2004 15:41:08 -0700 In-Reply-To: <20040430221722.27D35979C2@popserv2.redback.com> References: <20040430221722.27D35979C2@popserv2.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <787AD86D-9AF7-11D8-BA2C-00039375647A@cisco.com> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen X-Mailer: Apple Mail (2.613) 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: Fri, 30 Apr 2004 17:41:07 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Enke, Thanks for clarifying. I'm cool with this :-) - Tom On Apr 30, 2004, at 5:17 PM, Enke Chen wrote: > Hi, Tom: > > Please see inline. > >> Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> >> Content-Transfer-Encoding: 7bit >> Cc: idr@ietf.org >> From: Thomas Barron >> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt >> Date: Fri, 30 Apr 2004 14:46:43 -0500 >> To: Enke Chen >> > > [snip] > >> Well, if I'm right, it isn't always effective for this subset either. >> >> Consider the example in Fig. 3 where >> >> o R1, R2, R3 and R4 belong to one AS >> o R1 is a route reflector with R3 as its client. >> o R2 is a route reflector with R4 as its client. >> o External paths (a), (b) and (c) are as described in Fig. 4. >> >> >> +----+ 10 +----+ >> | R1 |--------------| R2 | >> +----+ +----+ >> | | >> | | >> | 5 | 20 >> | | >> | | >> +----+ +----+ >> | R3 | | R4 | >> +----+ +----+ >> / \ | >> / \ | >> (a) (b) (c) >> >> Figure 3 >> >> >> Path AS MED TimeofArrival >> a 1 0 2 >> b 2 20 1 >> c 2 10 5 >> >> Figure 4 >> >> Here is the oscillation: >> >> 1. R3 likes (b) over (a) (ToA) >> 2. R3 advertises (b) to R1 >> 3. R1 hears (b, c) and prefers (c) (MED) >> 4. R1 advertises (c) to R3 >> 5. R3 prefers (a) among (a, b, c) (MED + ToA) >> *NOTE* the arrival time of (c) is no longer 5, but it is some >> quantity >5. >> ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in >> favor of (c). >> 6. R3 advertises (a) to R1 >> 7. R1 hears (a, c) and prefers (a) (IGP) >> 8. R1 advertises (a) to R2 >> 9. R2 prefers (a) over (c) (lower IGP cost) >> 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 >> to R3 >> 11. R3 prefers (b) over (a) since (c) is no longer available to >> disqualify (b) and >> ToA(b) < ToA(a) > > > I see where your confusion was. The proposed algorithm in Sect. 4 of > the > draft does not really care about ToA ("Time of Arrival"). It just says > that "Do not switch the best path from one EBGP path to another EBGP > path when the comparison comes down to the route-id. > > So, in Step 11, if you follow the proposed algorithm, (a) will remain > as the best path on R3, and the churn will stop. > > I will need to think about other comments of yours, and try to clarify > the text in the next version. > > Thanks. -- Enke > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Apr 30 20:06:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14467 for ; Fri, 30 Apr 2004 20:06:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJi1X-0004iS-RV for idr-archive@ietf.org; Fri, 30 Apr 2004 20:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJi0e-0004cZ-00 for idr-archive@ietf.org; Fri, 30 Apr 2004 20:05:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJhzr-0004WT-00; Fri, 30 Apr 2004 20:04:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhwE-000498-Sd; Fri, 30 Apr 2004 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhpy-0002vL-6I for idr@optimus.ietf.org; Fri, 30 Apr 2004 19:54: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 TAA14011 for ; Fri, 30 Apr 2004 19:54:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJhpw-0003W7-A1 for idr@ietf.org; Fri, 30 Apr 2004 19:54:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhp6-0003Qo-00 for idr@ietf.org; Fri, 30 Apr 2004 19:53:40 -0400 Received: from bay17-f18.bay17.hotmail.com ([64.4.43.68] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BJhoj-0003KJ-00 for idr@ietf.org; Fri, 30 Apr 2004 19:53:17 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 Apr 2004 16:48:23 -0700 Received: from 64.94.142.142 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 30 Apr 2004 23:48:23 GMT X-Originating-IP: [64.94.142.142] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2004 23:48:23.0842 (UTC) FILETIME=[9FFC7820:01C42F0D] 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, 30 Apr 2004 23:48:23 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 unsubscribe >From: Yakov Rekhter >To: Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt >Date: Fri, 30 Apr 2004 10:56:17 -0700 > >Folks > > > Folks, > > > > This is to start the IDR WG Last Call on advancing > > draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. > > > > The Last Call ends April 28. > >The WG Last Call is over. > >Many thanks to the folks who read and commented on the document !!! > >The authors of the document are going to incorporate the comments >received during the WG Last Call and re-issue a revised draft. > >Yakov. > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Apr 30 20:18:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14938 for ; Fri, 30 Apr 2004 20:18: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 1BJi8l-0006V4-8y for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 20:13:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i410Dx53024980 for idr-archive@odin.ietf.org; Fri, 30 Apr 2004 20:13:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi1b-0004xt-5i for idr-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 20:06:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14493 for ; Fri, 30 Apr 2004 20:06:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJi1Z-0004ic-7h for idr-web-archive@ietf.org; Fri, 30 Apr 2004 20:06:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJi0f-0004cn-00 for idr-web-archive@ietf.org; Fri, 30 Apr 2004 20:05:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJhzr-0004WT-00; Fri, 30 Apr 2004 20:04:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhwE-000498-Sd; Fri, 30 Apr 2004 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhpy-0002vL-6I for idr@optimus.ietf.org; Fri, 30 Apr 2004 19:54: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 TAA14011 for ; Fri, 30 Apr 2004 19:54:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJhpw-0003W7-A1 for idr@ietf.org; Fri, 30 Apr 2004 19:54:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhp6-0003Qo-00 for idr@ietf.org; Fri, 30 Apr 2004 19:53:40 -0400 Received: from bay17-f18.bay17.hotmail.com ([64.4.43.68] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BJhoj-0003KJ-00 for idr@ietf.org; Fri, 30 Apr 2004 19:53:17 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 Apr 2004 16:48:23 -0700 Received: from 64.94.142.142 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 30 Apr 2004 23:48:23 GMT X-Originating-IP: [64.94.142.142] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2004 23:48:23.0842 (UTC) FILETIME=[9FFC7820:01C42F0D] 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, 30 Apr 2004 23:48:23 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 unsubscribe >From: Yakov Rekhter >To: Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt >Date: Fri, 30 Apr 2004 10:56:17 -0700 > >Folks > > > Folks, > > > > This is to start the IDR WG Last Call on advancing > > draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. > > > > The Last Call ends April 28. > >The WG Last Call is over. > >Many thanks to the folks who read and commented on the document !!! > >The authors of the document are going to incorporate the comments >received during the WG Last Call and re-issue a revised draft. > >Yakov. > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA05910 for ; Fri, 30 Apr 2004 20:04: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 1BJhwE-00049A-UG; Fri, 30 Apr 2004 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhpy-0002vL-6I for idr@optimus.ietf.org; Fri, 30 Apr 2004 19:54: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 TAA14011 for ; Fri, 30 Apr 2004 19:54:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJhpw-0003W7-A1 for idr@ietf.org; Fri, 30 Apr 2004 19:54:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhp6-0003Qo-00 for idr@ietf.org; Fri, 30 Apr 2004 19:53:40 -0400 Received: from bay17-f18.bay17.hotmail.com ([64.4.43.68] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BJhoj-0003KJ-00 for idr@ietf.org; Fri, 30 Apr 2004 19:53:17 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 Apr 2004 16:48:23 -0700 Received: from 64.94.142.142 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 30 Apr 2004 23:48:23 GMT X-Originating-IP: [64.94.142.142] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2004 23:48:23.0842 (UTC) FILETIME=[9FFC7820:01C42F0D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 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, 30 Apr 2004 23:48:23 +0000 unsubscribe >From: Yakov Rekhter >To: Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt >Date: Fri, 30 Apr 2004 10:56:17 -0700 > >Folks > > > Folks, > > > > This is to start the IDR WG Last Call on advancing > > draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. > > > > The Last Call ends April 28. > >The WG Last Call is over. > >Many thanks to the folks who read and commented on the document !!! > >The authors of the document are going to incorporate the comments >received during the WG Last Call and re-issue a revised draft. > >Yakov. > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA00223 for ; Fri, 30 Apr 2004 18:55: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 1BJgrR-0006eN-2J; Fri, 30 Apr 2004 18:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgjE-0004aO-89 for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:43: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 SAA10781 for ; Fri, 30 Apr 2004 18:43:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgjB-0004Jf-4B for idr@ietf.org; Fri, 30 Apr 2004 18:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgiF-0004DU-00 for idr@ietf.org; Fri, 30 Apr 2004 18:42:32 -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 1BJghQ-00040m-00 for idr@ietf.org; Fri, 30 Apr 2004 18:41:40 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2004 14:54:45 +0000 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UMf9W9024449; Fri, 30 Apr 2004 15:41:09 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id PAA12897; Fri, 30 Apr 2004 15:41:08 -0700 In-Reply-To: <20040430221722.27D35979C2@popserv2.redback.com> References: <20040430221722.27D35979C2@popserv2.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <787AD86D-9AF7-11D8-BA2C-00039375647A@cisco.com> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: Fri, 30 Apr 2004 17:41:07 -0500 Hi Enke, Thanks for clarifying. I'm cool with this :-) - Tom On Apr 30, 2004, at 5:17 PM, Enke Chen wrote: > Hi, Tom: > > Please see inline. > >> Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> >> Content-Transfer-Encoding: 7bit >> Cc: idr@ietf.org >> From: Thomas Barron >> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt >> Date: Fri, 30 Apr 2004 14:46:43 -0500 >> To: Enke Chen >> > > [snip] > >> Well, if I'm right, it isn't always effective for this subset either. >> >> Consider the example in Fig. 3 where >> >> o R1, R2, R3 and R4 belong to one AS >> o R1 is a route reflector with R3 as its client. >> o R2 is a route reflector with R4 as its client. >> o External paths (a), (b) and (c) are as described in Fig. 4. >> >> >> +----+ 10 +----+ >> | R1 |--------------| R2 | >> +----+ +----+ >> | | >> | | >> | 5 | 20 >> | | >> | | >> +----+ +----+ >> | R3 | | R4 | >> +----+ +----+ >> / \ | >> / \ | >> (a) (b) (c) >> >> Figure 3 >> >> >> Path AS MED TimeofArrival >> a 1 0 2 >> b 2 20 1 >> c 2 10 5 >> >> Figure 4 >> >> Here is the oscillation: >> >> 1. R3 likes (b) over (a) (ToA) >> 2. R3 advertises (b) to R1 >> 3. R1 hears (b, c) and prefers (c) (MED) >> 4. R1 advertises (c) to R3 >> 5. R3 prefers (a) among (a, b, c) (MED + ToA) >> *NOTE* the arrival time of (c) is no longer 5, but it is some >> quantity >5. >> ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in >> favor of (c). >> 6. R3 advertises (a) to R1 >> 7. R1 hears (a, c) and prefers (a) (IGP) >> 8. R1 advertises (a) to R2 >> 9. R2 prefers (a) over (c) (lower IGP cost) >> 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 >> to R3 >> 11. R3 prefers (b) over (a) since (c) is no longer available to >> disqualify (b) and >> ToA(b) < ToA(a) > > > I see where your confusion was. The proposed algorithm in Sect. 4 of > the > draft does not really care about ToA ("Time of Arrival"). It just says > that "Do not switch the best path from one EBGP path to another EBGP > path when the comparison comes down to the route-id. > > So, in Step 11, if you follow the proposed algorithm, (a) will remain > as the best path on R3, and the churn will stop. > > I will need to think about other comments of yours, and try to clarify > the text in the next version. > > Thanks. -- Enke > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA29879 for ; Fri, 30 Apr 2004 18:51: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 1BJghs-0004JY-9U; Fri, 30 Apr 2004 18:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgfF-0003b9-HG for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10535 for ; Fri, 30 Apr 2004 18:39:21 -0400 (EDT) From: jenny@redback.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgfC-0003pn-Ed for idr@ietf.org; Fri, 30 Apr 2004 18:39:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgeK-0003kR-00 for idr@ietf.org; Fri, 30 Apr 2004 18:38:29 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJgdR-0003fo-00 for idr@ietf.org; Fri, 30 Apr 2004 18:37:33 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id ECB36BF7F03; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28235-02; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 7C3B6BF7F02; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Received: (from jenny@localhost) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id PAA08889; Fri, 30 Apr 2004 15:37:33 -0700 (PDT) Message-Id: <200404302237.PAA08889@redback.com> Subject: Re: Yakov Rekhter: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document To: yakov@juniper.net Cc: jenny@redback.com, idr@ietf.org In-Reply-To: <20040430222422.E977215D3C3@popserv1.redback.com> from "Enke Chen" at Apr 30, 2004 03:24:21 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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: Fri, 30 Apr 2004 15:37:33 -0700 (PDT) I vote yes to have it be accepted as an IDR WG document. thanks, jenny > > > ------- Forwarded Message > > Message-Id: <200404301721.i3UHLjJ28638@merlot.juniper.net> > To: idr@ietf.org > From: Yakov Rekhter > Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document > Date: Fri, 30 Apr 2004 10:21:45 -0700 > > Folks > > We receive a request to accept draft-chen-bgp-avoid-transition-01.txt > as an IDR WG document. Please comment to the list. The deadline > for comments is May 14, 2004. > > Yakov. > - ------- Forwarded Message > > Date: Wed, 28 Apr 2004 10:13:29 -0700 > From: Enke Chen > To: yakov@juniper.net, skh@nexthop.com > cc: idr@ietf.org > Subject: draft-chen-bgp-avoid-transition-01.txt > > Hi, Yakov and Sue: > > I would like to request that the draft > be accepted as an IDR WG document. The draft was presented previosuly at an > IDR meeting. The algorithm described in the draft has been deployed for several > years. > > Thanks. -- Enke > > - - ------- Forwarded Message > > Message-Id: <200401201504.KAA02287@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt > Date: Tue, 20 Jan 2004 10:04:35 -0500 > > - - - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Avoid BGP Best Path Transition from One External to A > nother > Author(s) : E. Chen, S. Sangli > Filename : draft-chen-bgp-avoid-transition-01.txt > Pages : 5 > Date : 2004-1-19 > > In this document we propose an algorithm that would help improve the > overall network stability by avoiding BGP best path transition from > one external to another (under certain conditions) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt > > > - - ------- End of Forwarded Message > > > - ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA29151 for ; Fri, 30 Apr 2004 18:44: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 1BJgfu-0003jj-0s; Fri, 30 Apr 2004 18:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgUl-0001ee-81 for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:28:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09893 for ; Fri, 30 Apr 2004 18:28:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgUi-0002m2-9F for idr@ietf.org; Fri, 30 Apr 2004 18:28:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgTi-0002fA-00 for idr@ietf.org; Fri, 30 Apr 2004 18:27:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJgSm-0002TN-00 for idr@ietf.org; Fri, 30 Apr 2004 18:26:32 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 2EEA62D4863; Fri, 30 Apr 2004 18:25:58 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51072-01-47; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7E27B2D484A; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3UMPkN24616; Fri, 30 Apr 2004 18:25:46 -0400 (EDT) From: Jeffrey Haas To: Thomas Barron Cc: Enke Chen , idr@ietf.org Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt Message-ID: <20040430182545.L23652@nexthop.com> References: <20040430044924.A7A82979C2@popserv2.redback.com> <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com>; from tbarron@cisco.com on Fri, Apr 30, 2004 at 02:46:43PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 18:25:46 -0400 On Fri, Apr 30, 2004 at 02:46:43PM -0500, Thomas Barron wrote: > I am not myself aware of any other circumstances where the > indeterminism that this knob introduces has any bad effects. Or existing implementations of this knob that already do this. :-) Speaking as a former network operator of a tier-3 ISP, it took us a while to understand why otherwise very stable paths would all of a sudden take a sharp turn. This was typically noticed when the new stable path was poor for some reason. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA27712 for ; Fri, 30 Apr 2004 18:29:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgQN-00016s-AC; Fri, 30 Apr 2004 18:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgLp-00085j-Eq for idr@optimus.ietf.org; Fri, 30 Apr 2004 18:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09321 for ; Fri, 30 Apr 2004 18:19:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgLm-0001q1-IF for idr@ietf.org; Fri, 30 Apr 2004 18:19:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgKq-0001lf-00 for idr@ietf.org; Fri, 30 Apr 2004 18:18:21 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJgK1-0001hX-00 for idr@ietf.org; Fri, 30 Apr 2004 18:17:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2DE8B13F305; Fri, 30 Apr 2004 15:17:23 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25174-02; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id AD17313F302; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 27D35979C2; Fri, 30 Apr 2004 15:17:22 -0700 (PDT) To: Thomas Barron Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: Message from Thomas Barron of "Fri, 30 Apr 2004 14:46:43 CDT." <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> From: Enke Chen Message-Id: <20040430221722.27D35979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 15:17:21 -0700 Hi, Tom: Please see inline. > Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> > Content-Transfer-Encoding: 7bit > Cc: idr@ietf.org > From: Thomas Barron > Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt > Date: Fri, 30 Apr 2004 14:46:43 -0500 > To: Enke Chen > [snip] > Well, if I'm right, it isn't always effective for this subset either. > > Consider the example in Fig. 3 where > > o R1, R2, R3 and R4 belong to one AS > o R1 is a route reflector with R3 as its client. > o R2 is a route reflector with R4 as its client. > o External paths (a), (b) and (c) are as described in Fig. 4. > > > +----+ 10 +----+ > | R1 |--------------| R2 | > +----+ +----+ > | | > | | > | 5 | 20 > | | > | | > +----+ +----+ > | R3 | | R4 | > +----+ +----+ > / \ | > / \ | > (a) (b) (c) > > Figure 3 > > > Path AS MED TimeofArrival > a 1 0 2 > b 2 20 1 > c 2 10 5 > > Figure 4 > > Here is the oscillation: > > 1. R3 likes (b) over (a) (ToA) > 2. R3 advertises (b) to R1 > 3. R1 hears (b, c) and prefers (c) (MED) > 4. R1 advertises (c) to R3 > 5. R3 prefers (a) among (a, b, c) (MED + ToA) > *NOTE* the arrival time of (c) is no longer 5, but it is some > quantity >5. > ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in > favor of (c). > 6. R3 advertises (a) to R1 > 7. R1 hears (a, c) and prefers (a) (IGP) > 8. R1 advertises (a) to R2 > 9. R2 prefers (a) over (c) (lower IGP cost) > 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 > to R3 > 11. R3 prefers (b) over (a) since (c) is no longer available to > disqualify (b) and > ToA(b) < ToA(a) I see where your confusion was. The proposed algorithm in Sect. 4 of the draft does not really care about ToA ("Time of Arrival"). It just says that "Do not switch the best path from one EBGP path to another EBGP path when the comparison comes down to the route-id. So, in Step 11, if you follow the proposed algorithm, (a) will remain as the best path on R3, and the churn will stop. I will need to think about other comments of yours, and try to clarify the text in the next version. Thanks. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA22089 for ; Fri, 30 Apr 2004 17:35: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 1BJfUM-0004BJ-8O; Fri, 30 Apr 2004 17:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfEA-000660-3x for idr@optimus.ietf.org; Fri, 30 Apr 2004 17:07: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 RAA03107 for ; Fri, 30 Apr 2004 17:07:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfE7-0001LD-Tk for idr@ietf.org; Fri, 30 Apr 2004 17:07:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfDC-0001G2-00 for idr@ietf.org; Fri, 30 Apr 2004 17:06:23 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJfCH-000177-00 for idr@ietf.org; Fri, 30 Apr 2004 17:05:26 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 475682D4863 for ; Fri, 30 Apr 2004 17:04:56 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 49519-01-25 for ; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CD6B82D484A for ; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3UL4ii24497 for idr@ietf.org; Fri, 30 Apr 2004 17:04:44 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document Message-ID: <20040430170444.K23652@nexthop.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net>; from yakov@juniper.net on Mon, Apr 26, 2004 at 08:01:36AM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 17:04:44 -0400 On Mon, Apr 26, 2004 at 08:01:36AM -0700, Yakov Rekhter wrote: > Please comment on the attached. The deadline for comments is > May 10. I would urge that this document not be accepted. I think that a multi-session BGP is a better solution, perhaps with a graceful failover mechanism. I would offer many of the same reasons that Pedro did, specifically the inability to deal with a corrupt TCP stream. I believe that most of the shutdown reasons that we cared about have been addressed in the current cease subcode document undergoing last call. The prefix-limit issue is working itself out in other documents. One note on BGP multi-session with regards to operational issues: The BGP v2MIB includes the ability to montior multiple peering sessions to a single peer across the same src/dst addresses. > Yakov. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA19788 for ; Fri, 30 Apr 2004 17:11: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 1BJef2-00024V-SW; Fri, 30 Apr 2004 16:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFoj-0000WH-Sf for idr@optimus.ietf.org; Thu, 29 Apr 2004 13:59:25 -0400 Received: from dinara.foretec.com (dinaras-desktop.cnri.reston.va.us [10.27.16.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17149; Thu, 29 Apr 2004 13:59:18 -0400 (EDT) Message-Id: <6.1.0.6.2.20040429135711.02d606a0@odin> X-Sender: dinaras@odin X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: Pekka Savola , Yakov Rekhter From: Dinara Suleymanova Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Cc: Alex Zinin , , In-Reply-To: References: <200404201353.i3KDr1J39724@merlot.juniper.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: Thu, 29 Apr 2004 14:00:46 -0400 Hello, Could it be possible to UN-subscribe us/me (not sure what address was added on your subscription list) from your discussion list. Thanks a lot. Dinara Suleymanova At 12:35 PM 4/29/2004, Pekka Savola wrote: >On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > > 2) The definition of active route is bad. This fails in the > > > > situation where you need to export loopbacks/point-to-points to > > > > eBGP, but you have them in youro IGP. The specification does not > > > > consider them active (not used for forwarding), and they aren't > > > > exported. > > > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > > obviously this is no problem. Gargi Nalawade promised to submit > > > > text, but hasn't, and I think Yakov said something about being > > > > willing to incorporate that, but obviously hasn't. > > > > > > > > This was discussed at idr thread: > > > > > > > issue 11.2: active route, again > > > > > > > Otherwise, I think this was operationally good. > > > > > > Sue, Yakov, please check if the ball was dropped re this one. > > > > First of all, the consensus of the WG (as documented in > > draft-ietf-idr-bgp-issues) is to have the following text: > > > > In the context of this document we assume that a BGP speaker > > advertises to its peers only those routes that it itself uses (in > > this context a BGP speaker is said to "use" a BGP route if it is the > > most preferred BGP route and is used in forwarding). All other cases > > are outside the scope of this document. > > > > While this text does not cover the case described by Pekka, it does > > not preclude it either - handling the case described by Pekka > > is just outside the scope of the spec. > > > > With this in mind I suggest that the case described by Pekka > > should be covered in a separate Internet Draft. > >I think this is operationally a rather common (or even very common) >scenario, and it would seem very disadvantageous not to tackle it in >this specification. Further, there's major deployment of it (maybe >even multi-vendor -- probably) so there is considerable proof that it >works. > >It should be the default behaviour of BGP as that's which makes the >most sense, operationally. "BGP route is ... used by forwarding" does >not sufficiently cover the fact that people do use IGPs and there's >often overlap with IGP and BGP :). > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA18412 for ; Fri, 30 Apr 2004 16:58: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 1BJe7n-0003TU-2p; Fri, 30 Apr 2004 15:56:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe0Y-0000X3-BW for idr@optimus.ietf.org; Fri, 30 Apr 2004 15:49: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 PAA26771 for ; Fri, 30 Apr 2004 15:49:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJe0W-0006uv-Rb for idr@ietf.org; Fri, 30 Apr 2004 15:49:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdzY-0006qR-00 for idr@ietf.org; Fri, 30 Apr 2004 15:48:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BJdye-0006fM-00 for idr@ietf.org; Fri, 30 Apr 2004 15:47:16 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Apr 2004 12:46:56 -0700 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3UJki0Q027821; Fri, 30 Apr 2004 12:46:45 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id MAA18552; Fri, 30 Apr 2004 12:46:44 -0700 In-Reply-To: <20040430044924.A7A82979C2@popserv2.redback.com> References: <20040430044924.A7A82979C2@popserv2.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B3DC5E0-9ADF-11D8-BA2C-00039375647A@cisco.com> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: Fri, 30 Apr 2004 14:46:43 -0500 Hi Enke, Please see inline. On Apr 29, 2004, at 11:49 PM, Enke Chen wrote: > Hi, Tom: > > Thanks for your comments, and sorry that I forgot to reply to your > original > message earlier. Please see my comments inline. > >> Message-Id: >> Cc: yakov@juniper.net, skh@nexthop.com >> From: Thomas Barron >> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt >> To: Enke Chen , idr@ietf.org >> >> Hi Enke, >> >> Attached is an email I sent to IDR that discusses some issues >> around >> your draft. I don't think I have seen a reply. >> >> I will add now that since that note I've discussed and thought a >> bit >> more about your argument in 5.2, and I think it is quite clear (and is >> indeed the received opinion nowadays) that the essential ingredient in >> these route-oscillation problems is the interaction of Route >> Reflectors >> and IGP costs. > > MED plays a major role as well. > Sure. >> Using sufficiently high IGP costs between clusters will suffice to >> stop >> the churn both in your scenario and in other scenarios that don't >> involve >> router-id. > > Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR). > I rather like the way the point is put there. > Re-configuring the IGP metric is certainly an option. However, > changing the > IGP metric typically has much larger impact on the network traffic > matrix, > and may not be desirable or feasible. > Hmmm. Maybe my thinking is just too pedestrian, but I don't myself see the design drivers for setting up RRs and RCs such that clusters don't "cluster" in terms of IGP metrics as well. >> Indeed, in your scenario if by chance >> the times of arrival correspond in the same order to that determined >> by >> the router-ids the churn is not avoided by your algorithm either (the >> proof is tedious, but intuitively: start the scenario with the same >> ranking of tie-breakers, just use time-of-arrival instead of >> router-id; >> then realize that this order gets preserved as the oscillation >> proceeds >> because the repeatedly advertised-and-withdrawn route will always be >> "newest" and correspond to the largest router id in the original >> scenario.) > > Do you have a specific example? I would like to understand better > whether > the algorithm is applicable to the example. > > Unlike the ADD-PATH approach (which is a complete solution), the > proposed > algorithm is effective only for a subset of route oscillations. > Well, if I'm right, it isn't always effective for this subset either. Consider the example in Fig. 3 where o R1, R2, R3 and R4 belong to one AS o R1 is a route reflector with R3 as its client. o R2 is a route reflector with R4 as its client. o External paths (a), (b) and (c) are as described in Fig. 4. +----+ 10 +----+ | R1 |--------------| R2 | +----+ +----+ | | | | | 5 | 20 | | | | +----+ +----+ | R3 | | R4 | +----+ +----+ / \ | / \ | (a) (b) (c) Figure 3 Path AS MED TimeofArrival a 1 0 2 b 2 20 1 c 2 10 5 Figure 4 Here is the oscillation: 1. R3 likes (b) over (a) (ToA) 2. R3 advertises (b) to R1 3. R1 hears (b, c) and prefers (c) (MED) 4. R1 advertises (c) to R3 5. R3 prefers (a) among (a, b, c) (MED + ToA) *NOTE* the arrival time of (c) is no longer 5, but it is some quantity >5. ToA(c) > 5 > ToA(a), so (a) wins after MED eliminates (b) in favor of (c). 6. R3 advertises (a) to R1 7. R1 hears (a, c) and prefers (a) (IGP) 8. R1 advertises (a) to R2 9. R2 prefers (a) over (c) (lower IGP cost) 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 to R3 11. R3 prefers (b) over (a) since (c) is no longer available to disqualify (b) and ToA(b) < ToA(a) (Thanks to Nick Feamster, some time ago, for documenting these steps in a private email.) So, what we've done is keep everything the same in your example except that we've put ToA where you have Router ID. You make the point that "the BGP identifier of a route received from an external peer is just a random number" and that led me to think of the fact that the same can be said of the Time of Arrival. The interesting thing about your scenario is that the Time of Arrival of route (c) will change because it is withdrawn and readvertised, but since it is the highest that doesn't affect the order of the Times of Arrival so the formal parallelism with your case using BGP identifiers is preserved. >> >> But as I say in the attached, my argument is really with section >> 5.2, >> not with your overall proposal. There are implementations that >> provide >> a knob to do just what you are documenting and I agree that the BGP >> spec should provide for this option. >> >> Best regards, >> >> Tom Barron >> >> >>> From idr-admin@ietf.org Mon Nov 10 11:51:50 2003 >> From: Tom Barron >> To: idr@ietf.org >> Cc: Thomas P Barron >> Message-ID: <20031110174539.GA166@cfcentral.cisco.com> >> >> Enke, Srihari, et. al: >> >> I have some questions about draft-chen-bgp-avoid-transition-00.txt. >> I'm glad to see this draft since there are implementations out there >> using the route-selection algorithm this draft proposes, and since the >> proposed algorith is not what is documented in RFC1771 or in >> draft-ietf-idr-bgr4-22.txt section 9.1.2.2. >> >> First, is it the intent of this draft that the proposed algorithm >> should *replace* the algorithm currently documented, or just that >> it be added as an option? > > It is a backward-compatible extension to the base BGP spec.. Whether > it is ON or OFF, that is an implementation decision. (If that is the > intent of your question.) > Good. Yes, that is the intention of my question, and I suggest that you make this point explicitly in your draft. >> >> Second, while I think the claim in 5.1 that the proposed algorithm >> avoids an unnecessary best path transition is quite straightforward, >> there ought to be some discussion of concerns that have been expressed >> about the consequent lack of determinism in route selection. See >> for example section 7.1.4 of >> draft-ietf-idr-bgp4-experience-protocol-03.txt >> and appendix A of "Guidelines for Interdomain Traffic Engineering" by >> Feamster, Borkenhagen, and Rexford. I'm not personally convinced >> that this local indeterminism is a real big deal, but I do think it >> needs some discussion in your draft. > > As I recall, the only practical concern raised so far is the impact on > BGP testing script by the proposed algorithm, and the subject (impact > on the testing script) seems to be outside the scope of the document. > Please let me know if I have missed any other practical concerns. > Well, without getting into issues about whether Traffic Engineering is "practical" :-), I suggest that you might want to explicitly state that there may be circumstances in which an ISP is doing TE where this knob would be best left off. I am not myself aware of any other circumstances where the indeterminism that this knob introduces has any bad effects. >> >> Third, I found the argument at 5.2 to the effect that the proposed >> algorithm reduces route oscillation a bit unclear. Maybe just a bit >> more text is needed, but it seems to me that the really essential >> ingredient in your setup in figure 1 and figure 2 is not the router >> ID, but the high intracluster IGP metric. Indeed, though you cite >> RFC3345, that work focuses on IGP metrics, not router ID, as a >> critical factor for "type 1" oscillation scenarios (yours appears to >> be a type 1 variant.) If adjusting IGP metrics is sufficient to fix >> both your oscillation scenario and other type 1 scenarios, but >> shifting from Router ID selection to the proposed time-of-arrival >> algorithm is not sufficient for type 1 scenarios in general, then the >> contribution of the proposed algorithm to the route oscillation >> problem does not seem very decisive. On the other hand, if using the >> proposed time-of-arrival algorithm yields a general solution to >> oscillation problems, then this reader at least did not get that from >> the draft as currently written. >> > > We will work on adding more text to clarify. > >> I'm glad you folks wrote this draft. I hope it's clear that I'm >> not against your proposal, but rather want to address some gaps >> in my own understanding of the issues that surround it. >> > > Some of the gaps are with the text in the document :-) > We will work on improving it in the next version. > > Regards, > > -- Enke > Thanks, - Tom _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04272 for ; Fri, 30 Apr 2004 14:31:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceN-00016C-7m; Fri, 30 Apr 2004 14:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcZS-00008U-Uc for idr@optimus.ietf.org; Fri, 30 Apr 2004 14:17: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 OAA19678 for ; Fri, 30 Apr 2004 14:17:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcZQ-0006Zz-E1 for idr@ietf.org; Fri, 30 Apr 2004 14:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcYS-0006VY-00 for idr@ietf.org; Fri, 30 Apr 2004 14:16:08 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BJcXU-0006Oi-00 for idr@ietf.org; Fri, 30 Apr 2004 14:15:08 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3UIEc5O029460; Fri, 30 Apr 2004 11:14:38 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3UIEcOB029457; Fri, 30 Apr 2004 11:14:38 -0700 (PDT) Message-Id: <200404301814.i3UIEcOB029457@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Yakov Rekhter , Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: References: <200404301715.i3UHFQJ27453@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: Fri, 30 Apr 2004 11:14:38 -0700 (PDT) Pekka Savola writes: > On Fri, 30 Apr 2004, Yakov Rekhter wrote: >> > I think this is operationally a rather common (or even very >> common) > scenario, and it would seem very disadvantageous not to >> tackle it in > this specification. Further, there's major >> deployment of it (maybe > even multi-vendor -- probably) so there >> is considerable proof that it > works. > > It should be the >> default behaviour of BGP as that's which makes the > most sense, >> operationally. "BGP route is ... used by forwarding" does > not >> sufficiently cover the fact that people do use IGPs and there's > >> often overlap with IGP and BGP :). >> >> People do use IGPs, and there is interaction between IGPs and BGP. >> >> It is just that the based BGP protocol spec is *not* the place to >> document the interaction between BGP and IGPs. > I have to disagree here. BGP is useless without IGP. Failing to > consider that would mean a specifition disconnected from the > reality. Pekka, BGP is only one of the miriad of components necessary in a router. There are advantages in documenting interactions between such components but these are typically not done in the base specification. One simply cannot put all the bits of information required to make bgp "useful" in the base specification and still have a readable document. moreever the iteraction procedures that you seem to want to document are not something the wg has achieved consensus on. there are still different opinions on this topic and different deployed behaviours. Thus including this topic in the base protocol spec seems to me to be contrary to the original goals of revising the specification. I would also like to point out that several outher people have expressed the opinion that this topic should be left out of the base spec. In fact i would claim that there is consensus on that ammong the wg. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04078 for ; Fri, 30 Apr 2004 14:29:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceF-00013R-46; Fri, 30 Apr 2004 14:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcWX-0008J5-EV for idr@optimus.ietf.org; Fri, 30 Apr 2004 14:14: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 OAA19498 for ; Fri, 30 Apr 2004 14:14:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcWU-0006J9-Ts for idr@ietf.org; Fri, 30 Apr 2004 14:14:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcV3-000659-00 for idr@ietf.org; Fri, 30 Apr 2004 14:12:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcTg-0005pX-04 for idr@ietf.org; Fri, 30 Apr 2004 14:11:12 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJcFk-0006VX-MU for idr@ietf.org; Fri, 30 Apr 2004 13:56:48 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3UHuHBm036112 for ; Fri, 30 Apr 2004 10:56:17 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHuHJ37685 for ; Fri, 30 Apr 2004 10:56:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301756.i3UHuHJ37685@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18739.1083347777.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 10:56:17 -0700 Folks > Folks, > > This is to start the IDR WG Last Call on advancing > draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. > > The Last Call ends April 28. The WG Last Call is over. Many thanks to the folks who read and commented on the document !!! The authors of the document are going to incorporate the comments received during the WG Last Call and re-issue a revised draft. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA01602 for ; Fri, 30 Apr 2004 14:03: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 1BJcGv-0005eC-0K; Fri, 30 Apr 2004 13:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcFv-0005RO-VS for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18200 for ; Fri, 30 Apr 2004 13:56:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcFt-0004sO-LS for idr@ietf.org; Fri, 30 Apr 2004 13:56:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcEN-0004am-00 for idr@ietf.org; Fri, 30 Apr 2004 13:55:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcDE-0004Sn-00 for idr@ietf.org; Fri, 30 Apr 2004 13:54:12 -0400 Received: from prattle.redback.com ([155.53.12.9]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJc3X-00061s-Qv for idr@ietf.org; Fri, 30 Apr 2004 13:44:11 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D281B259469; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25789-06; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 4D91125946B; Fri, 30 Apr 2004 10:43:38 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 3875F15D3C3; Fri, 30 Apr 2004 10:43:37 -0700 (PDT) To: Jeffrey Haas Cc: Yakov Rekhter , idr@ietf.org, enke@redback.com Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Message from Jeffrey Haas of "Thu, 29 Apr 2004 22:40:18 EDT." <20040429224018.F21778@nexthop.com> From: Enke Chen Message-Id: <20040430174337.3875F15D3C3@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 10:43:36 -0700 Hi, Jeff: > From: Jeffrey Haas > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt > Message-ID: <20040429224018.F21778@nexthop.com> > References: <200404162121.i3GLLDJ87448@merlot.juniper.net> > > Additional nits: > > Their modification could potential result in routing loops. > > s/potential/potentially/ > > In the changes, also note that you corrected transitive to > non-transitive in the introduction. > > I think ROUTER_ID should be consistently substituted with "BGP Identifier" > per the current use in draft-ietf-idr-bgp4-23 Ok. > > one. Using this attribute an RR can identify if the routing > information is looped back to the same cluster due to mis- > configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST, > > > s/is looped/has looped/ Ok. > > Original text: > If the BGP Identifiers of two paths are equal when compared in the > route selection, then the path with the shorter CLUSTER_LIST length > > Suggested change: > The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the > BGP specification) is modified by inserting the following rule > between f and g: > > The BGP Speaker SHOULD prefer all routes with the shorter > CLUSTER_LIST length. If no CLUSTER_LIST path attribute is present, > the CLUSTER_LIST length is zero. will revise the text along these lines. Thanks. -- Enke > > On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote: > > Folks, > > > > During the Last Call it would be greatly appreciated if folks would > > read the document and comment on it to the IDR mailing list. In > > other words, we need "yes, looks good" or "should fix this and > > that", not just silence. > > > > Thanks in advance. > > > > Yakov. > > -- > Jeff Haas > NextHop Technologies > > _______________________________________________ > 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 (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA29320 for ; Fri, 30 Apr 2004 13:42: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 1BJbxc-0002lV-Pj; Fri, 30 Apr 2004 13:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbp5-0001Ez-Jv for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:29:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16790 for ; Fri, 30 Apr 2004 13:29:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbp3-0002zo-Hz for idr@ietf.org; Fri, 30 Apr 2004 13:29:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbo5-0002v8-00 for idr@ietf.org; Fri, 30 Apr 2004 13:28:14 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BJbnE-0002k6-00 for idr@ietf.org; Fri, 30 Apr 2004 13:27:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3UHQnBm035999; Fri, 30 Apr 2004 10:26:49 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHQnJ30213; Fri, 30 Apr 2004 10:26:49 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301726.i3UHQnJ30213@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11789.1083346009.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 10:26:49 -0700 Folks > We receive a request to accept draft-lange-flexible-bgp-communities-02.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 28, 2004. The draft didn't generate enough support to justify its acceptance as an IDR WG document. Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28890 for ; Fri, 30 Apr 2004 13:37: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 1BJbor-0001En-6t; Fri, 30 Apr 2004 13:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbkA-0000Oj-R5 for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:24: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 NAA16156 for ; Fri, 30 Apr 2004 13:24:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbk8-0002Qt-Q3 for idr@ietf.org; Fri, 30 Apr 2004 13:24:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbjI-0002N9-00 for idr@ietf.org; Fri, 30 Apr 2004 13:23:17 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJbiO-0002EV-00 for idr@ietf.org; Fri, 30 Apr 2004 13:22:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3UHLol85668 for ; Fri, 30 Apr 2004 10:21:50 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHLjJ28638 for ; Fri, 30 Apr 2004 10:21:45 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301721.i3UHLjJ28638@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10769.1083345705.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document 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, 30 Apr 2004 10:21:45 -0700 Folks We receive a request to accept draft-chen-bgp-avoid-transition-01.txt as an IDR WG document. Please comment to the list. The deadline for comments is May 14, 2004. Yakov. ------- Forwarded Message Date: Wed, 28 Apr 2004 10:13:29 -0700 From: Enke Chen To: yakov@juniper.net, skh@nexthop.com cc: idr@ietf.org Subject: draft-chen-bgp-avoid-transition-01.txt Hi, Yakov and Sue: I would like to request that the draft be accepted as an IDR WG document. The draft was presented previosuly at an IDR meeting. The algorithm described in the draft has been deployed for several years. Thanks. -- Enke - ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoid BGP Best Path Transition from One External to A nother Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt - ------- End of Forwarded Message ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28421 for ; Fri, 30 Apr 2004 13:32: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 1BJbl3-0000ct-Hu; Fri, 30 Apr 2004 13:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbhN-0008P2-0u for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:21:17 -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 NAA15936 for ; Fri, 30 Apr 2004 13:21:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbhL-0002Av-15 for idr@ietf.org; Fri, 30 Apr 2004 13:21:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbgK-00025e-00 for idr@ietf.org; Fri, 30 Apr 2004 13:20:13 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJbfT-0001za-00 for idr@ietf.org; Fri, 30 Apr 2004 13:19:19 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3UHIiZ21669; Fri, 30 Apr 2004 20:18:44 +0300 From: Pekka Savola To: Yakov Rekhter cc: Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: <200404301715.i3UHFQJ27453@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 20:18:44 +0300 (EEST) On Fri, 30 Apr 2004, Yakov Rekhter wrote: > > I think this is operationally a rather common (or even very common) > > scenario, and it would seem very disadvantageous not to tackle it in > > this specification. Further, there's major deployment of it (maybe > > even multi-vendor -- probably) so there is considerable proof that it > > works. > > > > It should be the default behaviour of BGP as that's which makes the > > most sense, operationally. "BGP route is ... used by forwarding" does > > not sufficiently cover the fact that people do use IGPs and there's > > often overlap with IGP and BGP :). > > People do use IGPs, and there is interaction between IGPs and BGP. > > It is just that the based BGP protocol spec is *not* the place to > document the interaction between BGP and IGPs. I have to disagree here. BGP is useless without IGP. Failing to consider that would mean a specifition disconnected from the reality. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28001 for ; Fri, 30 Apr 2004 13:26:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbi9-0008VM-Kd; Fri, 30 Apr 2004 13:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbeK-0007TX-AQ for idr@optimus.ietf.org; Fri, 30 Apr 2004 13:18: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 NAA15841 for ; Fri, 30 Apr 2004 13:18:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbeI-0001yJ-7u for idr@ietf.org; Fri, 30 Apr 2004 13:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbdJ-0001uq-00 for idr@ietf.org; Fri, 30 Apr 2004 13:17:06 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJbcM-0001or-00 for idr@ietf.org; Fri, 30 Apr 2004 13:16:07 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3UHFYl85648; Fri, 30 Apr 2004 10:15:34 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3UHFQJ27453; Fri, 30 Apr 2004 10:15:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404301715.i3UHFQJ27453@merlot.juniper.net> To: Pekka Savola cc: Alex Zinin , ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: Your message of "Thu, 29 Apr 2004 19:35:00 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9409.1083345326.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 10:15:26 -0700 Pekka, > On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > > 2) The definition of active route is bad. This fails in the > > > > situation where you need to export loopbacks/point-to-points to > > > > eBGP, but you have them in youro IGP. The specification does not > > > > consider them active (not used for forwarding), and they aren't > > > > exported. > > > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > > obviously this is no problem. Gargi Nalawade promised to submit > > > > text, but hasn't, and I think Yakov said something about being > > > > willing to incorporate that, but obviously hasn't. > > > > > > > > This was discussed at idr thread: > > > > > > > issue 11.2: active route, again > > > > > > > Otherwise, I think this was operationally good. > > > > > > Sue, Yakov, please check if the ball was dropped re this one. > > > > First of all, the consensus of the WG (as documented in > > draft-ietf-idr-bgp-issues) is to have the following text: > > > > In the context of this document we assume that a BGP speaker > > advertises to its peers only those routes that it itself uses (in > > this context a BGP speaker is said to "use" a BGP route if it is the > > most preferred BGP route and is used in forwarding). All other cases > > are outside the scope of this document. > > > > While this text does not cover the case described by Pekka, it does > > not preclude it either - handling the case described by Pekka > > is just outside the scope of the spec. > > > > With this in mind I suggest that the case described by Pekka > > should be covered in a separate Internet Draft. > > I think this is operationally a rather common (or even very common) > scenario, and it would seem very disadvantageous not to tackle it in > this specification. Further, there's major deployment of it (maybe > even multi-vendor -- probably) so there is considerable proof that it > works. > > It should be the default behaviour of BGP as that's which makes the > most sense, operationally. "BGP route is ... used by forwarding" does > not sufficiently cover the fact that people do use IGPs and there's > often overlap with IGP and BGP :). People do use IGPs, and there is interaction between IGPs and BGP. It is just that the based BGP protocol spec is *not* the place to document the interaction between BGP and IGPs. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA29371 for ; Fri, 30 Apr 2004 01:04: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 1BJQ1G-00073c-MI; Fri, 30 Apr 2004 00:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPz3-0006WW-Ly for idr@optimus.ietf.org; Fri, 30 Apr 2004 00:50: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 AAA25458 for ; Fri, 30 Apr 2004 00:50:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPyx-000526-Js for idr@ietf.org; Fri, 30 Apr 2004 00:50:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPxy-0004xT-00 for idr@ietf.org; Fri, 30 Apr 2004 00:49:39 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJPxm-0004tC-00 for idr@ietf.org; Fri, 30 Apr 2004 00:49:26 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AF6598AABAF; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18738-09; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 1BF348AABAD; Thu, 29 Apr 2004 21:49:25 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id A7A82979C2; Thu, 29 Apr 2004 21:49:24 -0700 (PDT) To: Thomas Barron Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: Message from Thomas Barron of "Wed, 28 Apr 2004 14:38:30 CDT." From: Enke Chen Message-Id: <20040430044924.A7A82979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 21:49:24 -0700 Hi, Tom: Thanks for your comments, and sorry that I forgot to reply to your original message earlier. Please see my comments inline. > Message-Id: > Cc: yakov@juniper.net, skh@nexthop.com > From: Thomas Barron > Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt > To: Enke Chen , idr@ietf.org > > Hi Enke, > > Attached is an email I sent to IDR that discusses some issues around > your draft. I don't think I have seen a reply. > > I will add now that since that note I've discussed and thought a bit > more about your argument in 5.2, and I think it is quite clear (and is > indeed the received opinion nowadays) that the essential ingredient in > these route-oscillation problems is the interaction of Route Reflectors > and IGP costs. MED plays a major role as well. > Using sufficiently high IGP costs between clusters will suffice to stop > the churn both in your scenario and in other scenarios that don't involve > router-id. Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR). Re-configuring the IGP metric is certainly an option. However, changing the IGP metric typically has much larger impact on the network traffic matrix, and may not be desirable or feasible. > Indeed, in your scenario if by chance > the times of arrival correspond in the same order to that determined by > the router-ids the churn is not avoided by your algorithm either (the > proof is tedious, but intuitively: start the scenario with the same > ranking of tie-breakers, just use time-of-arrival instead of router-id; > then realize that this order gets preserved as the oscillation proceeds > because the repeatedly advertised-and-withdrawn route will always be > "newest" and correspond to the largest router id in the original > scenario.) Do you have a specific example? I would like to understand better whether the algorithm is applicable to the example. Unlike the ADD-PATH approach (which is a complete solution), the proposed algorithm is effective only for a subset of route oscillations. > > But as I say in the attached, my argument is really with section 5.2, > not with your overall proposal. There are implementations that provide > a knob to do just what you are documenting and I agree that the BGP > spec should provide for this option. > > Best regards, > > Tom Barron > > > >From idr-admin@ietf.org Mon Nov 10 11:51:50 2003 > From: Tom Barron > To: idr@ietf.org > Cc: Thomas P Barron > Message-ID: <20031110174539.GA166@cfcentral.cisco.com> > > Enke, Srihari, et. al: > > I have some questions about draft-chen-bgp-avoid-transition-00.txt. > I'm glad to see this draft since there are implementations out there > using the route-selection algorithm this draft proposes, and since the > proposed algorith is not what is documented in RFC1771 or in > draft-ietf-idr-bgr4-22.txt section 9.1.2.2. > > First, is it the intent of this draft that the proposed algorithm > should *replace* the algorithm currently documented, or just that > it be added as an option? It is a backward-compatible extension to the base BGP spec.. Whether it is ON or OFF, that is an implementation decision. (If that is the intent of your question.) > > Second, while I think the claim in 5.1 that the proposed algorithm > avoids an unnecessary best path transition is quite straightforward, > there ought to be some discussion of concerns that have been expressed > about the consequent lack of determinism in route selection. See > for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt > and appendix A of "Guidelines for Interdomain Traffic Engineering" by > Feamster, Borkenhagen, and Rexford. I'm not personally convinced > that this local indeterminism is a real big deal, but I do think it > needs some discussion in your draft. As I recall, the only practical concern raised so far is the impact on BGP testing script by the proposed algorithm, and the subject (impact on the testing script) seems to be outside the scope of the document. Please let me know if I have missed any other practical concerns. > > Third, I found the argument at 5.2 to the effect that the proposed > algorithm reduces route oscillation a bit unclear. Maybe just a bit > more text is needed, but it seems to me that the really essential > ingredient in your setup in figure 1 and figure 2 is not the router > ID, but the high intracluster IGP metric. Indeed, though you cite > RFC3345, that work focuses on IGP metrics, not router ID, as a > critical factor for "type 1" oscillation scenarios (yours appears to > be a type 1 variant.) If adjusting IGP metrics is sufficient to fix > both your oscillation scenario and other type 1 scenarios, but > shifting from Router ID selection to the proposed time-of-arrival > algorithm is not sufficient for type 1 scenarios in general, then the > contribution of the proposed algorithm to the route oscillation > problem does not seem very decisive. On the other hand, if using the > proposed time-of-arrival algorithm yields a general solution to > oscillation problems, then this reader at least did not get that from > the draft as currently written. > We will work on adding more text to clarify. > I'm glad you folks wrote this draft. I hope it's clear that I'm > not against your proposal, but rather want to address some gaps > in my own understanding of the issues that surround it. > Some of the gaps are with the text in the document :-) We will work on improving it in the next version. Regards, -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA27178 for ; Fri, 30 Apr 2004 00:27: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 1BJPa9-000353-CO; Fri, 30 Apr 2004 00:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJPU2-0002Bx-3B for idr@optimus.ietf.org; Fri, 30 Apr 2004 00:18:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23832 for ; Fri, 30 Apr 2004 00:18:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJPTw-0001h8-AR for idr@ietf.org; Fri, 30 Apr 2004 00:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJPT3-0001ch-00 for idr@ietf.org; Fri, 30 Apr 2004 00:17:42 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJPSl-0001Y3-00 for idr@ietf.org; Fri, 30 Apr 2004 00:17:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C616A2D488C; Fri, 30 Apr 2004 00:16:57 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27746-01-23; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 95E552D484A; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U4GkW22292; Fri, 30 Apr 2004 00:16:46 -0400 (EDT) From: Jeffrey Haas To: Pekka Savola Cc: Pedro Roque Marques , Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <20040430001646.J21778@nexthop.com> References: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, Apr 22, 2004 at 12:17:53PM +0300 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 30 Apr 2004 00:16:46 -0400 On Thu, Apr 22, 2004 at 12:17:53PM +0300, Pekka Savola wrote: > For what it's worth, it seems to me that this memo is a solution > looking for the problem. > > Why do we need this in the first place? To "standardize" commonly > used communities? To give the users more tools to mess up their > routing, or to allow the users to make the ISP's policy more complex? > > I'm skeptical about the usefulness of this approach. FWIW, I think this was proposed for a couple of reasons: Once upon a draft, draft-ietf-grow-bgp-redistribution-00.txt tried to formalize some very common bgp policy that communities are used for. Specific examples are: proxy as-path prepend proxy append no-export proxy append no-announce filters included: to an as to two as's to a cidr prefix (v4 only) to a 4byte as The operations are not novel as the survey that Olivier Bonaventure and Bruno Quoitin did as part of the original GROW draft. The draft was suggested as a way to take common operational procuedure and simplify configuration. The primary objection at the time were: 1. We can't represent ipv6 information due to the length of the extended community. 2. Why don't we just make an uber community and be done with it? Flexible communities adds this as well as adding the concept of neighbor classes and being (well...) flexible enough to accomodate future needs as well as deprecating existing mechanisms. My personal suggestions: o Is the underlying functionality useful regardless of the encoding? o If so, is the encoding clean enough or potentially too cumbersome? o Should we keep the encoding of things like route-target, etc. out of this? > - it might make sense to switch the order of Length and "ASN" fields > for better alignment. I thought this had been mentioned at SF IETF. :-) > Length could also include the ASN field. (Maybe > this would be a more typical TLV encoding?) Perhaps it would be better to simply strip any 4byte ASes upon export when 4byte ASes aren't supported. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA24080 for ; Thu, 29 Apr 2004 23:32:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOe6-0001tt-7w; Thu, 29 Apr 2004 23:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJOYt-0001JV-S8 for idr@optimus.ietf.org; Thu, 29 Apr 2004 23:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21057 for ; Thu, 29 Apr 2004 23:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJOYo-0003dp-Fu for idr@ietf.org; Thu, 29 Apr 2004 23:19:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJOXw-0003ZH-00 for idr@ietf.org; Thu, 29 Apr 2004 23:18:41 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJOX3-0003Pn-00 for idr@ietf.org; Thu, 29 Apr 2004 23:17:45 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E539A2D483A for ; Thu, 29 Apr 2004 23:17:19 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26630-01-22 for ; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 724EC2D4888 for ; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U3H8P22174 for idr@ietf.org; Thu, 29 Apr 2004 23:17:08 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt Message-ID: <20040429231708.H21778@nexthop.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com>; from enke@redback.com on Wed, Apr 28, 2004 at 10:13:29AM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 23:17:08 -0400 On Wed, Apr 28, 2004 at 10:13:29AM -0700, Enke Chen wrote: > I would like to request that the draft > be accepted as an IDR WG document. The draft was presented previosuly at an > IDR meeting. The algorithm described in the draft has been deployed for several I would echo many of Tom's comments. Specifically: 1. This doesn't solve med oscillation - or at least I don't think so. 2. Having this as a knob would be handy. Whether this knob is turned on by default is an interesting question and the matter of some debate. 3. By having such a knob, those who prefer deterministic path selection in their network can have it while those who prefer path stability with the caveat that it is temporally deterministic could have their way too - perhaps on a border router basis. Suggested changes: Remove 5.2 Add something along the lines of item 3 above? Be a bit more specific about where in the tie breaking algorithm this goes. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA22113 for ; Thu, 29 Apr 2004 22:56:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJO7F-0005ZL-AH; Thu, 29 Apr 2004 22:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJNz5-00043V-Vt for idr@optimus.ietf.org; Thu, 29 Apr 2004 22:42: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 WAA19581 for ; Thu, 29 Apr 2004 22:42:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJNyz-0000U0-9V for idr@ietf.org; Thu, 29 Apr 2004 22:42:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJNy3-0000QH-00 for idr@ietf.org; Thu, 29 Apr 2004 22:41:36 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BJNxV-0000IF-00 for idr@ietf.org; Thu, 29 Apr 2004 22:41:01 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5F51F2D4881; Thu, 29 Apr 2004 22:40:30 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26110-01-4; Thu, 29 Apr 2004 22:40:19 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E06E92D4888; Thu, 29 Apr 2004 22:40:18 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3U2eIa22113; Thu, 29 Apr 2004 22:40:18 -0400 (EDT) From: Jeffrey Haas To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt Message-ID: <20040429224018.F21778@nexthop.com> References: <200404162121.i3GLLDJ87448@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404162121.i3GLLDJ87448@merlot.juniper.net>; from yakov@juniper.net on Fri, Apr 16, 2004 at 02:21:13PM -0700 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 22:40:18 -0400 Additional nits: > Their modification could potential result in routing loops. s/potential/potentially/ In the changes, also note that you corrected transitive to non-transitive in the introduction. I think ROUTER_ID should be consistently substituted with "BGP Identifier" per the current use in draft-ietf-idr-bgp4-23 one. Using this attribute an RR can identify if the routing information is looped back to the same cluster due to mis- configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST, s/is looped/has looped/ Original text: If the BGP Identifiers of two paths are equal when compared in the route selection, then the path with the shorter CLUSTER_LIST length Suggested change: The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the BGP specification) is modified by inserting the following rule between f and g: The BGP Speaker SHOULD prefer all routes with the shorter CLUSTER_LIST length. If no CLUSTER_LIST path attribute is present, the CLUSTER_LIST length is zero. On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote: > Folks, > > During the Last Call it would be greatly appreciated if folks would > read the document and comment on it to the IDR mailing list. In > other words, we need "yes, looks good" or "should fix this and > that", not just silence. > > Thanks in advance. > > Yakov. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA27203 for ; Thu, 29 Apr 2004 15:45: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 1BJHDD-0006pw-K9; Thu, 29 Apr 2004 15:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH3N-0001pm-In for idr@optimus.ietf.org; Thu, 29 Apr 2004 15:18:37 -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 PAA21769 for ; Thu, 29 Apr 2004 15:18:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH3H-0003kb-0v for idr@ietf.org; Thu, 29 Apr 2004 15:18:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH2W-0003h7-00 for idr@ietf.org; Thu, 29 Apr 2004 15:17:45 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJH1y-0003ce-00 for idr@ietf.org; Thu, 29 Apr 2004 15:17:10 -0400 Received: from camail03.ca.alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id i3TJHBaC022913 for ; Thu, 29 Apr 2004 15:17:12 -0400 (EDT) Received: from alcatel.com ([138.120.234.32]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HWY5KN00.BDU; Thu, 29 Apr 2004 15:17:11 -0400 Message-ID: <40915437.12CA79AA@alcatel.com> From: Cheng-Yin Lee Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zinin@psg.com, idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: Thu, 29 Apr 2004 15:15:03 -0400 Hello, Alex Zinin wrote: >>2.2. BGP Algorithms >> >> >> BGP uses an algorithm that is neither a pure distance vector >> algorithm or a pure link state algorithm. It is instead a modified >> distance vector algorithm referred to as a "Path Vector" algorithm >> that uses path information to avoid traditional distance vector >> problems. Each route within BGP pairs destination with path >> information to that destination. Path information (also known as >> AS_PATH information) is stored within the AS_PATH attribute in BGP. >> This allows BGP to reconstruct large portions of overall topology >> whenever required. >> >> > >I've always been uncomfortable with documents saying that BGP reconstructs the >overall topology. It doesn't really do this like the link-state protocols do, >for example. > > Is this sentence "This allows BGP to reconstruct large portions of overall topology ...." talking about using AS_PATH as topology information or reconstructing routes/paths? >>6.1.1. CPU utilization >> >> >> An important and fundamental feature of BGP is that BGP's CPU >> utilization depends only on the stability of the Internet. If the >> Internet is stable, then the only link bandwidth and router CPU >> cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE >> messages. The KEEPALIVE messages are exchanged only between peers. >> The suggested frequency of the exchange is 30 seconds. The KEEPALIVE >> messages are quite short (19 octets), and require virtually no >> processing. As a result, the bandwidth consumed by the KEEPALIVE >> messages is about 5 bits/sec. Operational experience confirms that >> the overhead (in terms of bandwidth and CPU) associated with the >> KEEPALIVE messages should be viewed as negligible. >> >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The >> >> > >While theoretically the text is correct and we could talk about periods of >stability and instability of the Internet, I wonder if this text is still >applicable from the practical perspective. I.e., the continuous churn that the >Internet BGP speakers experience ensures that they practically always have >something to process. > >Probably instead of talking about periods of "Internet stability" and "Internet >instability" we could talk about something like "periods of stable state among >BGP speakers when they do no have new updates to communicate to each other". > > > >>Meyer and Patel Section 6.1.1. [Page 10] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> greatest overhead per UPDATE message occurs when each UPDATE message >> contains only a single network. It should be pointed out that in >> practice routing changes exhibit strong locality with respect to the >> AS path. That is, routes that change are likely to have common AS >> path. In this case, multiple networks can be grouped into a single >> UPDATE message, thus significantly reducing the amount of bandwidth >> required (see also Appendix F.1 of [BGP4]). >> >> Since in the steady state the link bandwidth and router CPU cycles >> consumed by the BGP protocol are dependent only on the stability of >> the Internet, it follows that BGP should have no scaling problems in >> the areas of link bandwidth and router CPU utilization. >> >> > >Not sure I follow here. What is meant by the "steady state" here? If it means >convergence on a stable topology after the initial exchange of updates, then why >talk about "stability of the Internet"? > > I took this to mean that whenever a BGP session starts, there's a > potentially long initial exchange of routes, and we mean to exclude > that startup transient. > > But, of course, we're back to the "stable Internet" paradigm. :^( >In other words, if the Internet is >unstable then can we say that the BGP speakers are in steady state? In the lack >of topology changes, it seems that the consumption should instead depend on the >number of peers (affects KEEPALIVE processing) and the number of persistently >oscillating routes potentially present in the network... > I agree the term Internet instability may not be clear enough in this draft. It seems that the draft is saying : BGP CPU's utilization depends mostly on number of route exchanges and KEEPALIVE message processing is not significant [The route exchanges can be due to a topology change, router startup, configuration changes, oscillating routes, ..... And oscillating routes may be triggered by topology change, router startup, configuration changes .....] ? If that's the case, instead of saying Internet stability or instability as follows : "If the Internet is stable, then the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages. " perhaps the draft could say something along this line : "If there are no route exchanges, then the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages". > that as the Internet grows, the overall stability of the inter-AS > connectivity of the Internet can be controlled. > Please specify how it is assumed to be "controlled", e.g. through > operational practices. > I believe historically this meant route-flap damping I thought route-flap damping may also slow down route convergence (i.e. may cause instability in turn...) Regards Cheng-Yin _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA17408 for ; Thu, 29 Apr 2004 13:40: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 1BJFFE-0006m1-Lg; Thu, 29 Apr 2004 13:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEXW-0004hp-3A for idr@optimus.ietf.org; Thu, 29 Apr 2004 12:37: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 MAA12795 for ; Thu, 29 Apr 2004 12:37:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEXR-0002Zk-6V for idr@ietf.org; Thu, 29 Apr 2004 12:37:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEWa-0002FP-00 for idr@ietf.org; Thu, 29 Apr 2004 12:36:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJEVY-0001bN-00 for idr@ietf.org; Thu, 29 Apr 2004 12:35:32 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TGZ0000473; Thu, 29 Apr 2004 19:35:00 +0300 From: Pekka Savola To: Yakov Rekhter cc: Alex Zinin , , Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: <200404201353.i3KDr1J39724@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 19:35:00 +0300 (EEST) On Tue, 20 Apr 2004, Yakov Rekhter wrote: > > > 2) The definition of active route is bad. This fails in the > > > situation where you need to export loopbacks/point-to-points to > > > eBGP, but you have them in youro IGP. The specification does not > > > consider them active (not used for forwarding), and they aren't > > > exported. > > > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > > obviously this is no problem. Gargi Nalawade promised to submit > > > text, but hasn't, and I think Yakov said something about being > > > willing to incorporate that, but obviously hasn't. > > > > > > This was discussed at idr thread: > > > > > issue 11.2: active route, again > > > > > Otherwise, I think this was operationally good. > > > > Sue, Yakov, please check if the ball was dropped re this one. > > First of all, the consensus of the WG (as documented in > draft-ietf-idr-bgp-issues) is to have the following text: > > In the context of this document we assume that a BGP speaker > advertises to its peers only those routes that it itself uses (in > this context a BGP speaker is said to "use" a BGP route if it is the > most preferred BGP route and is used in forwarding). All other cases > are outside the scope of this document. > > While this text does not cover the case described by Pekka, it does > not preclude it either - handling the case described by Pekka > is just outside the scope of the spec. > > With this in mind I suggest that the case described by Pekka > should be covered in a separate Internet Draft. I think this is operationally a rather common (or even very common) scenario, and it would seem very disadvantageous not to tackle it in this specification. Further, there's major deployment of it (maybe even multi-vendor -- probably) so there is considerable proof that it works. It should be the default behaviour of BGP as that's which makes the most sense, operationally. "BGP route is ... used by forwarding" does not sufficiently cover the fact that people do use IGPs and there's often overlap with IGP and BGP :). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12516 for ; Thu, 29 Apr 2004 12:36: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 1BJEEc-00068z-In; Thu, 29 Apr 2004 12:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDrs-0006Kh-2o for idr@optimus.ietf.org; Thu, 29 Apr 2004 11:54: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 LAA10574 for ; Thu, 29 Apr 2004 11:54:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDrn-0006DP-FC for idr@ietf.org; Thu, 29 Apr 2004 11:54:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDqq-0005x8-00 for idr@ietf.org; Thu, 29 Apr 2004 11:53:29 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJDqF-0005fP-00 for idr@ietf.org; Thu, 29 Apr 2004 11:52:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TFqEv32267; Thu, 29 Apr 2004 18:52:14 +0300 From: Pekka Savola To: Andrew Lange cc: Pedro Roque Marques , Yakov Rekhter , Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <7663189.1082986622@[192.168.5.191]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 18:52:14 +0300 (EEST) On Mon, 26 Apr 2004, Andrew Lange wrote: > > Why do we need this in the first place? To "standardize" commonly > > used communities? To give the users more tools to mess up their > > routing, or to allow the users to make the ISP's policy more complex? > > Here is some additional text for the introduction which, I hope, will > answer your questions. > > There is a clear demand by BGP-savvy customers to have enhanced control > over their route announcements. Today this demand is addressed by custom, > complex and difficult to manage community policies. There is no > consistency across providers, except for the NO_EXPORT well known community > specified in RFC1997. There are more well-known communities for common > policies specified in this document to help provide commonality and ease of > maintenance. The current route policies required to provide enhanced BGP > services are very cumbersome. The larger space provided in flexible > communities, and the introduction of neighbor classes significantly ease > the implementation and maintenance burdens for service providers. > > Service providers also often tag their data based on where and from whom > they learned it (peer, customer, geographic origin). The flexible > community, and the neighbor class application especially, make both > assigning inbound communities and matching on outbound peers significantly > easier and less error prone. > > In addition, community values today are simply too small and too rigidly > defined to allow for the growth of the Internet. For example, encoding > IPv6 address and an action to take on them is simply impossible. This is clearer. However, there are still many things I find disturbing, based on the quick glance: - operator losing the control of the network. For us, the #1 thing in the network is being able to control the traffic flows etc. as we see fit except with the tools we give to the customers. So, this would seem to call for a statement that acting upon these communities should be disabled unless explicitly enabled. - IPv4/IPv6 addresses: these are very poor keys for communities and probably should not be included -- or is there a specific usage case for them? If there are needed, could these be implemented as a form of extended communities then? - usability for the customer: these are only applicable to the customer if the customer has already negotiated with the ISP that the ISP supports these communities, and has marked each and all the BGP sessions it has accordingly ("peer", "upstream", "transit", etc.); they aren't useful otherwise. This seems like a rather big leap to me. So what these are is a replacement for those ISPs who already community-based schemes to something "standardized". It doesn't help much (except a little with set-up complexity) with other ISPs, so it isn't a silver bullet. - similar to IPv4/IPv6 address applicability, the applicability of VPN communities seems a bit fuzzy. In addition to those the bandwidth community seems particularly unnecessary. - this appears to be confusing: The Flexible Community attribute MUST NOT be used to modify the BGP best path selection algorithm in a way that leads to forwarding loops. ==> does this allow that to happen? Do we want to specify anything that would lead to that? On the other hand, if we allow flexibility, the customer always has a possibility to shoot himself in the foot, and the protocol should not prevent that? (btw, the refs need to be split to normative/informative, and an IPR statement needs to be added.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10169 for ; Thu, 29 Apr 2004 12:06: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 1BJDqU-0005xo-Cr; Thu, 29 Apr 2004 11:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDUT-00084w-Gv for idr@optimus.ietf.org; Thu, 29 Apr 2004 11:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09187 for ; Thu, 29 Apr 2004 11:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDUP-0007T2-7v for idr@ietf.org; Thu, 29 Apr 2004 11:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDTV-0007Ds-00 for idr@ietf.org; Thu, 29 Apr 2004 11:29:22 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJDSi-0006jU-00 for idr@ietf.org; Thu, 29 Apr 2004 11:28:32 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TFMhJ31771; Thu, 29 Apr 2004 18:22:43 +0300 From: Pekka Savola To: Parantap Lahiri cc: "'Gargi Nalawade'" , "'Pedro Roque Marques'" , , "'Yakov Rekhter'" Subject: RE: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <002601c42d39$22a08ef0$a3922799@mcilink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 18:22:43 +0300 (EEST) On Wed, 28 Apr 2004, Parantap Lahiri wrote: > If the community has already made its mind that BGP is going to carry most > of the services, the vendor community has accepted to undertake that > incremental complexity and the operators have accepted to live with the > risk, then resisting this draft from going to WG, is a mixed signal. If > everyone HAS to live with multiple AFI/SAFI in the same session, they might > as well get their control and not think about how many sets of sessions they > should run in their infrastructure. Why would anyone want have to live with multiple AFI/SAFI in the same session if (s)he could set them up as separate sessions? It seems that soft-notify accomplishes a subset of goals which multisession (and the like accomplish), but with a lot of additional issues. The implementation or deployment complexity is probably roughly equal. So, this makes me wonder why soft-notify should go forward here at all? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06143 for ; Thu, 29 Apr 2004 11:14: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 1BJD34-000053-60; Thu, 29 Apr 2004 11:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCo3-0004sK-Vl for idr@optimus.ietf.org; Thu, 29 Apr 2004 10:46: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 KAA06569 for ; Thu, 29 Apr 2004 10:46:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCns-0003Bn-G6 for idr@ietf.org; Thu, 29 Apr 2004 10:46:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCmz-0002w8-00 for idr@ietf.org; Thu, 29 Apr 2004 10:45:25 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1BJCmQ-0002g9-00 for idr@ietf.org; Thu, 29 Apr 2004 10:44:50 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TEiIF11189; Thu, 29 Apr 2004 09:44:19 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J4L1A4SX; Thu, 29 Apr 2004 07:44:19 -0700 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN02N1D; Thu, 29 Apr 2004 10:44:17 -0400 Message-ID: <409114C0.4080801@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document References: <200404151359.i3FDxsJ92103@merlot.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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: Thu, 29 Apr 2004 10:44:16 -0400 In response to some of the comments made on this draft in the WG, we have made some changes to the 01 version of the draft. The following is the link to the new draft which is based of 00 version as suggested by some. http://ndzh.com/idr/Drafts/draft-chavali-bgp-prefixlimit-02.txt This is has been submitted as an internet draft today. Please forward your your comments to the list. Thanks srikanth chavali _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA20922 for ; Wed, 28 Apr 2004 19:10:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy5y-0003bq-CQ; Wed, 28 Apr 2004 19:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxxq-0000Vt-US for idr@optimus.ietf.org; Wed, 28 Apr 2004 18:55:38 -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 SAA01111 for ; Wed, 28 Apr 2004 18:55:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxxm-0000Rr-Gb for idr@ietf.org; Wed, 28 Apr 2004 18:55:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxwq-0000MV-00 for idr@ietf.org; Wed, 28 Apr 2004 18:54:37 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIxw1-0000EP-00 for idr@ietf.org; Wed, 28 Apr 2004 18:53:45 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SMrDW9028605 for ; Wed, 28 Apr 2004 15:53:14 -0700 (PDT) Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3SJcXjO013688; Wed, 28 Apr 2004 12:38:33 -0700 (PDT) Received: from [64.101.210.173] (dhcp-64-101-210-173.cisco.com [64.101.210.173]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id MAA11077; Wed, 28 Apr 2004 12:38:32 -0700 In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/mixed; boundary=Apple-Mail-4--352788604 Message-Id: Cc: yakov@juniper.net, skh@nexthop.com From: Thomas Barron Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt To: Enke Chen , idr@ietf.org X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 28 Apr 2004 14:38:30 -0500 --Apple-Mail-4--352788604 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Apr 28, 2004, at 12:13 PM, Enke Chen wrote: > Hi, Yakov and Sue: > > I would like to request that the draft > > be accepted as an IDR WG document. The draft was presented previosuly > at an > IDR meeting. The algorithm described in the draft has been deployed > for several > years. > > Thanks. -- Enke > > ------- Forwarded Message > > Message-Id: <200401201504.KAA02287@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt > Date: Tue, 20 Jan 2004 10:04:35 -0500 > > - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Avoid BGP Best Path Transition from One External to Another > Author(s) : E. Chen, S. Sangli > Filename : draft-chen-bgp-avoid-transition-01.txt > Pages : 5 > Date : 2004-1-19 > > In this document we propose an algorithm that would help improve the > overall network stability by avoiding BGP best path transition from > one external to another (under certain conditions) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition > -01.txt > > > ------- End of Forwarded Message > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > Hi Enke, Attached is an email I sent to IDR that discusses some issues around your draft. I don't think I have seen a reply. I will add now that since that note I've discussed and thought a bit more about your argument in 5.2, and I think it is quite clear (and is indeed the received opinion nowadays) that the essential ingredient in these route-oscillation problems is the interaction of Route Reflectors and IGP costs. Using sufficiently high IGP costs between clusters will suffice to stop the churn both in your scenario and in other scenarios that don't involve router-id. Indeed, in your scenario if by chance the times of arrival correspond in the same order to that determined by the router-ids the churn is not avoided by your algorithm either (the proof is tedious, but intuitively: start the scenario with the same ranking of tie-breakers, just use time-of-arrival instead of router-id; then realize that this order gets preserved as the oscillation proceeds because the repeatedly advertised-and-withdrawn route will always be "newest" and correspond to the largest router id in the original scenario.) But as I say in the attached, my argument is really with section 5.2, not with your overall proposal. There are implementations that provide a knob to do just what you are documenting and I agree that the BGP spec should provide for this option. Best regards, Tom Barron --Apple-Mail-4--352788604 Content-Type: text/plain; x-unix-mode=0600; name="reduce-route-oscillation-discussion.txt" Content-Disposition: attachment; filename=reduce-route-oscillation-discussion.txt Content-Transfer-Encoding: 7bit >From idr-admin@ietf.org Mon Nov 10 11:51:50 2003 From: Tom Barron To: idr@ietf.org Cc: Thomas P Barron Message-ID: <20031110174539.GA166@cfcentral.cisco.com> Enke, Srihari, et. al: I have some questions about draft-chen-bgp-avoid-transition-00.txt. I'm glad to see this draft since there are implementations out there using the route-selection algorithm this draft proposes, and since the proposed algorith is not what is documented in RFC1771 or in draft-ietf-idr-bgr4-22.txt section 9.1.2.2. First, is it the intent of this draft that the proposed algorithm should *replace* the algorithm currently documented, or just that it be added as an option? Second, while I think the claim in 5.1 that the proposed algorithm avoids an unnecessary best path transition is quite straightforward, there ought to be some discussion of concerns that have been expressed about the consequent lack of determinism in route selection. See for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt and appendix A of "Guidelines for Interdomain Traffic Engineering" by Feamster, Borkenhagen, and Rexford. I'm not personally convinced that this local indeterminism is a real big deal, but I do think it needs some discussion in your draft. Third, I found the argument at 5.2 to the effect that the proposed algorithm reduces route oscillation a bit unclear. Maybe just a bit more text is needed, but it seems to me that the really essential ingredient in your setup in figure 1 and figure 2 is not the router ID, but the high intracluster IGP metric. Indeed, though you cite RFC3345, that work focuses on IGP metrics, not router ID, as a critical factor for "type 1" oscillation scenarios (yours appears to be a type 1 variant.) If adjusting IGP metrics is sufficient to fix both your oscillation scenario and other type 1 scenarios, but shifting from Router ID selection to the proposed time-of-arrival algorithm is not sufficient for type 1 scenarios in general, then the contribution of the proposed algorithm to the route oscillation problem does not seem very decisive. On the other hand, if using the proposed time-of-arrival algorithm yields a general solution to oscillation problems, then this reader at least did not get that from the draft as currently written. I'm glad you folks wrote this draft. I hope it's clear that I'm not against your proposal, but rather want to address some gaps in my own understanding of the issues that surround it. - Tom Barron _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --Apple-Mail-4--352788604 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-4--352788604-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA20550 for ; Wed, 28 Apr 2004 19:05:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxyD-0000Xg-1b; Wed, 28 Apr 2004 18:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxmA-0006H6-4l for idr@optimus.ietf.org; Wed, 28 Apr 2004 18:43: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 SAA00596 for ; Wed, 28 Apr 2004 18:43:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxm5-0007Nv-LZ for idr@ietf.org; Wed, 28 Apr 2004 18:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxl9-0007Jq-00 for idr@ietf.org; Wed, 28 Apr 2004 18:42:31 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIxkQ-0007C5-00 for idr@ietf.org; Wed, 28 Apr 2004 18:41:46 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3SMfH5O025163; Wed, 28 Apr 2004 15:41:17 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3SMfHhx025160; Wed, 28 Apr 2004 15:41:17 -0700 (PDT) Message-Id: <200404282241.i3SMfHhx025160@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: yakov@juniper.net, skh@nexthop.com, idr@ietf.org Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt In-Reply-To: <20040428171329.B1AB915D3C2@popserv1.redback.com> References: <20040428171329.B1AB915D3C2@popserv1.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 28 Apr 2004 15:41:17 -0700 (PDT) Enke Chen writes: > Hi, Yakov and Sue: I would like to request that the draft > be accepted as an IDR WG > document. The draft was presented previosuly at an IDR meeting. The > algorithm described in the draft has been deployed for several > years. my turn to cheer: i believe this should be a wg document. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16598 for ; Wed, 28 Apr 2004 18:13: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 1BIwxJ-0006x3-PQ; Wed, 28 Apr 2004 17:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwlD-0008I5-CI for idr@optimus.ietf.org; Wed, 28 Apr 2004 17:38: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 RAA24991 for ; Wed, 28 Apr 2004 17:38:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwl9-0001tm-Jq for idr@ietf.org; Wed, 28 Apr 2004 17:38:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwkH-0001q6-00 for idr@ietf.org; Wed, 28 Apr 2004 17:37:34 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1BIwjK-0001jX-00 for idr@ietf.org; Wed, 28 Apr 2004 17:36:34 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWW0056ZH0ZWT@firewall.mci.com> for idr@ietf.org; Wed, 28 Apr 2004 21:29:23 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWW00H01GZ2BG@pmismtp02.mcilink.com>; Wed, 28 Apr 2004 21:29:23 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWW00GDAH0DVT@pmismtp02.mcilink.com>; Wed, 28 Apr 2004 21:29:01 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] Soft-Notify as an IDR WG document In-reply-to: <200404281646.i3SGkEde024649@roque-bsd.juniper.net> To: "'Pedro Roque Marques'" Cc: idr@ietf.org, "'Yakov Rekhter'" Message-id: <004901c42d67$d2e12b70$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 28 Apr 2004 17:29:01 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA16598 I am not sure if it was a complete misrepresentation of your argument. You do mention in your mail that >> Besides multisession is 10x easier to implement and deploy since it can use existing state machines. As an operator we definitely do keep network management implications in our mind while choosing any mechanism and I appreciate your concern there. And the fact that adding BGP complexity is worrying some is a good sign. Though whatever choice you make has tactical as well as strategic implications. BGP is becoming a generic protocol to transport not only routing but also service information. Now the question is whether to control these information flows at a higher AFI/SAFI level or to split them apart and tie them down to lower tcp session level? Definitely the operators are familiar with managing BGP TCP sessions, but if you are too quick to arrive at the latter alternative and discard the former one for lack of NMS functions you may run the risk of not assigning the right function to the right component. I have no idea how the number of AFI/SAFI and their functions there-of are going to evolve in future, but if we start bundling them together in subsets and tie the control mechanisms of each subset to a tcp session, it has to be more conscious and well thought decision than a quick tactical one depending on short-term merit. I will be interested in understanding how multisession BGP stacks up with running completely separate BGP between the same end points. [I understand that its not doable now, but just trying to gauge the merit] -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Wednesday, April 28, 2004 12:46 PM To: Parantap Lahiri Cc: idr@ietf.org; 'Yakov Rekhter' Subject: RE: [Idr] Soft-Notify as an IDR WG document Parantap Lahiri writes: > Now, here is this thread, where a part of the same community is > suggesting that giving individual soft control to each AFI/SAFI pair > would make BGP protocol implementation more complicated than > necessary and we should push the complexity to the operator > world. That is fine and in some ways sane, but in most ways > confusing. This is a misrepresentation of the argument. The point is that you cannot achieve individual control for afi/safi without adding the necessary diagnostics and support for tools and management on the operator side. Not to mention understanding of how mecanisms work. The multisession draft is nicer alternative for several reasons including the fact that it fits into the current management framework and follows a model understood by all. The point is not wether to achieve a given end goal but to find the approach that gets us there with less pain. and which can be built incrementally. As an operator i would expect you to be supportive of the need to consider the network management implications before picking a solution. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA25666 for ; Wed, 28 Apr 2004 13:43:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIssq-0007ls-7x; Wed, 28 Apr 2004 13:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIskU-0005Vf-7e for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:21: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 NAA00323 for ; Wed, 28 Apr 2004 13:21:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIskQ-0000XL-Vn for idr@ietf.org; Wed, 28 Apr 2004 13:21:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsjV-0000UP-00 for idr@ietf.org; Wed, 28 Apr 2004 13:20:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIsis-0000Pn-00 for idr@ietf.org; Wed, 28 Apr 2004 13:19:50 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E04A52D49FC for ; Wed, 28 Apr 2004 13:19:21 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 75888-01-30 for ; Wed, 28 Apr 2004 13:19:08 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 81F122D4869 for ; Wed, 28 Apr 2004 13:19:08 -0400 (EDT) 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: draft-chen-bgp-avoid-transition-01.txt Thread-Index: AcQtRCsdoWQqfWGLQSW/EtgbXqiGfgAAKEsA From: "Susan Hares" To: "Enke Chen" , Cc: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] RE: draft-chen-bgp-avoid-transition-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, 28 Apr 2004 13:19:08 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA25666 Enke: Please drop me a note to indicate where the draft has been deployed and in what routers. Are there inter-operable implementations? Sue -----Original Message----- From: Enke Chen [mailto:enke@redback.com] Sent: Wednesday, April 28, 2004 1:13 PM To: yakov@juniper.net; Susan Hares Cc: idr@ietf.org Subject: draft-chen-bgp-avoid-transition-01.txt Hi, Yakov and Sue: I would like to request that the draft be accepted as an IDR WG document. The draft was presented previosuly at an IDR meeting. The algorithm described in the draft has been deployed for several years. Thanks. -- Enke ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoid BGP Best Path Transition from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA25397 for ; Wed, 28 Apr 2004 13:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIssj-0007kd-MJ; Wed, 28 Apr 2004 13:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsf9-00047t-6Z for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29890 for ; Wed, 28 Apr 2004 13:15:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsf5-00008l-VU for idr@ietf.org; Wed, 28 Apr 2004 13:15:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIseA-00001K-00 for idr@ietf.org; Wed, 28 Apr 2004 13:14:58 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BIscl-0007hT-00 for idr@ietf.org; Wed, 28 Apr 2004 13:13:32 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5508CA6EBA1; Wed, 28 Apr 2004 10:13:32 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09989-06; Wed, 28 Apr 2004 10:13:32 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 8A422A6EBA0; Wed, 28 Apr 2004 10:13:30 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id B1AB915D3C2; Wed, 28 Apr 2004 10:13:29 -0700 (PDT) To: yakov@juniper.net, skh@nexthop.com Cc: idr@ietf.org From: Enke Chen Message-Id: <20040428171329.B1AB915D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-chen-bgp-avoid-transition-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, 28 Apr 2004 10:13:29 -0700 Hi, Yakov and Sue: I would like to request that the draft be accepted as an IDR WG document. The draft was presented previosuly at an IDR meeting. The algorithm described in the draft has been deployed for several years. Thanks. -- Enke ------- Forwarded Message Message-Id: <200401201504.KAA02287@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt Date: Tue, 20 Jan 2004 10:04:35 -0500 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoid BGP Best Path Transition from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-chen-bgp-avoid-transition-01.txt Pages : 5 Date : 2004-1-19 In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA24594 for ; Wed, 28 Apr 2004 13:24:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsWZ-0001jn-Aa; Wed, 28 Apr 2004 13:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsQ7-0008P8-GT for idr@optimus.ietf.org; Wed, 28 Apr 2004 13:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28716 for ; Wed, 28 Apr 2004 13:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsQ4-0006ra-HM for idr@ietf.org; Wed, 28 Apr 2004 13:00:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsPB-0006p2-00 for idr@ietf.org; Wed, 28 Apr 2004 12:59:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIsOh-0006mF-00 for idr@ietf.org; Wed, 28 Apr 2004 12:58:59 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7C0042D4A05 for ; Wed, 28 Apr 2004 12:58:30 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74394-01-73 for ; Wed, 28 Apr 2004 12:58:17 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E95D02D4877 for ; Wed, 28 Apr 2004 12:58:17 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Message-ID: Thread-Topic: [Idr] draft-keyur-prefixlimit-orf-00 Thread-Index: AcQtQPIUe5/VlB+ZRma6+cq5bG02PAAACVhw From: "Susan Hares" To: "John G. Scudder" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 28 Apr 2004 12:58:17 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA24594 John: Read document before I sent the message. Complexity came in -01 came in allowing ORFs as well as the global limits. We set it up as an option and worked out the coordination deals So, we'll just trying to allow both methods. Capabilities and Dynamic capabilities provide a simple way to determine the 3 prefix limits: warning, stop receiving and disconnect per peer. The support of dynamic allows re-negotiation easily on a connection basis. ORFs is too heavy weighted for that simple focus. If we are trying to travel light, ORFs are like adding a 2 ton weight to your baggage. Sue -----Original Message----- From: John G. Scudder [mailto:jgs@cisco.com] Sent: Wednesday, April 28, 2004 12:50 PM To: Susan Hares Cc: idr@ietf.org Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Sue, Sorry you feel that way. As you might imagine, I have a different perspective, which is that I tried to suggest a way to simplify the specification, but instead found the -01 version to be more complex. Since I clearly didn't communicate the idea effectively enough at the Minneapolis meeting it seemed like it would be more productive to express it in the form of a fully written specification instead of a list of comments. If you haven't read draft-keyur-prefixlimit-orf-00 then please do (it's short). If having read it you do think that it's more complex, I'd love to discuss the reasons. Of course, I would also like to hear what other members of the WG think. We'd be happy to make reasonable changes to the acknowledgement section if you'd like to communicate what the problem is, either on or off list. Respectfully, --John At 12:36 PM -0400 4/28/04, Susan Hares wrote: >John: > >Well this is amazing. Since you suggested the complexity... >Perhaps you changed your mind. > >We put the complex ORF policy in because you state >Cisco did not support dynamic configuration. >In simplifying this, I do not find people wanting to >go to an ORF policy.  > >Sue > >PS - your acknowledgement section is problematic. > >-----Original Message----- >From: John G. Scudder [mailto:jgs@cisco.com] >Sent: Wednesday, April 28, 2004 11:19 AM >To: idr@ietf.org >Subject: [Idr] draft-keyur-prefixlimit-orf-00 > > >Folks, > >As others have noted, while the underlying goal of >draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the >actual mechanisms proposed are more complex than is necessary. > >We've written another draft which we think provides the needed >functionality with less complexity, along the lines of what I >suggested at the meeting in Minneapolis. In summary we introduce a >new ORF-type which carries a 32 bit prefix limit, and also use the >PERMIT/DENY flag to signal whether enforcement of the limit will be >done by dropping the session or not. The draft is a tad over four >pages plus six pages of IETF boilerplate. > >The draft has been submitted as an I-D. Until it's available in the >usual places, you can find it at >ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt > >Discussion of the draft would be welcome. > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA24392 for ; Wed, 28 Apr 2004 13:21: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 1BIsUb-0000vI-8G; Wed, 28 Apr 2004 13:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsIK-0006Wo-Bn for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:52: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 MAA28246 for ; Wed, 28 Apr 2004 12:52:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsIH-0006RX-9K for idr@ietf.org; Wed, 28 Apr 2004 12:52:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsHR-0006PR-00 for idr@ietf.org; Wed, 28 Apr 2004 12:51:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BIsGu-0006LX-00 for idr@ietf.org; Wed, 28 Apr 2004 12:50:56 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SGoNW9006923; Wed, 28 Apr 2004 09:50:23 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA10499; Wed, 28 Apr 2004 12:50:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: "Susan Hares" From: "John G. Scudder" Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Cc: Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 28 Apr 2004 12:50:28 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA24392 Sue, Sorry you feel that way. As you might imagine, I have a different perspective, which is that I tried to suggest a way to simplify the specification, but instead found the -01 version to be more complex. Since I clearly didn't communicate the idea effectively enough at the Minneapolis meeting it seemed like it would be more productive to express it in the form of a fully written specification instead of a list of comments. If you haven't read draft-keyur-prefixlimit-orf-00 then please do (it's short). If having read it you do think that it's more complex, I'd love to discuss the reasons. Of course, I would also like to hear what other members of the WG think. We'd be happy to make reasonable changes to the acknowledgement section if you'd like to communicate what the problem is, either on or off list. Respectfully, --John At 12:36 PM -0400 4/28/04, Susan Hares wrote: >John: > >Well this is amazing. Since you suggested the complexity... >Perhaps you changed your mind. > >We put the complex ORF policy in because you state >Cisco did not support dynamic configuration. >In simplifying this, I do not find people wanting to >go to an ORF policy.  > >Sue > >PS - your acknowledgement section is problematic. > >-----Original Message----- >From: John G. Scudder [mailto:jgs@cisco.com] >Sent: Wednesday, April 28, 2004 11:19 AM >To: idr@ietf.org >Subject: [Idr] draft-keyur-prefixlimit-orf-00 > > >Folks, > >As others have noted, while the underlying goal of >draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the >actual mechanisms proposed are more complex than is necessary. > >We've written another draft which we think provides the needed >functionality with less complexity, along the lines of what I >suggested at the meeting in Minneapolis. In summary we introduce a >new ORF-type which carries a 32 bit prefix limit, and also use the >PERMIT/DENY flag to signal whether enforcement of the limit will be >done by dropping the session or not. The draft is a tad over four >pages plus six pages of IETF boilerplate. > >The draft has been submitted as an I-D. Until it's available in the >usual places, you can find it at >ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt > >Discussion of the draft would be welcome. > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA24002 for ; Wed, 28 Apr 2004 13:13: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 1BIsTb-0000Up-Uf; Wed, 28 Apr 2004 13:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsES-0005if-N0 for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:48: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 MAA27913 for ; Wed, 28 Apr 2004 12:48:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsEP-0006DN-N4 for idr@ietf.org; Wed, 28 Apr 2004 12:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsDQ-00068H-00 for idr@ietf.org; Wed, 28 Apr 2004 12:47:21 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIsCp-00061U-00 for idr@ietf.org; Wed, 28 Apr 2004 12:46:43 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3SGkE5O024652; Wed, 28 Apr 2004 09:46:14 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3SGkEde024649; Wed, 28 Apr 2004 09:46:14 -0700 (PDT) Message-Id: <200404281646.i3SGkEde024649@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Parantap Lahiri Cc: idr@ietf.org, "'Yakov Rekhter'" Subject: RE: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <002601c42d39$22a08ef0$a3922799@mcilink.com> References: <002601c42d39$22a08ef0$a3922799@mcilink.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 28 Apr 2004 09:46:14 -0700 (PDT) Parantap Lahiri writes: > Now, here is this thread, where a part of the same community is > suggesting that giving individual soft control to each AFI/SAFI pair > would make BGP protocol implementation more complicated than > necessary and we should push the complexity to the operator > world. That is fine and in some ways sane, but in most ways > confusing. This is a misrepresentation of the argument. The point is that you cannot achieve individual control for afi/safi without adding the necessary diagnostics and support for tools and management on the operator side. Not to mention understanding of how mecanisms work. The multisession draft is nicer alternative for several reasons including the fact that it fits into the current management framework and follows a model understood by all. The point is not wether to achieve a given end goal but to find the approach that gets us there with less pain. and which can be built incrementally. As an operator i would expect you to be supportive of the need to consider the network management implications before picking a solution. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23474 for ; Wed, 28 Apr 2004 13:04: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 1BIsHw-0006Qh-Mv; Wed, 28 Apr 2004 12:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISYH-0000Y2-OX for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:23: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 JAA29542 for ; Tue, 27 Apr 2004 09:23:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISYB-0005ln-9e for idr@ietf.org; Tue, 27 Apr 2004 09:23:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISXK-0005Xu-00 for idr@ietf.org; Tue, 27 Apr 2004 09:22:11 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BISWs-0005IF-00 for idr@ietf.org; Tue, 27 Apr 2004 09:21:42 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Apr 2004 14:21:13 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802B138F3@baker.datcon.co.uk> From: Michael Dell To: "'Yakov Rekhter'" , idr@ietf.org Subject: RE: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 27 Apr 2004 14:20:55 +0100 Yakov I have no particular comments on or issues with the draft. However, we were slightly surprised by the time difference between this draft being published and then moving to last call - about 2 minutes by my count. I can't see any details on what is motivating this draft in the proceedings of the last couple of IETF meetings. Apologies if I'm the only reader of this list that doesn't know the history behind this modification, but perhaps you could summarise for me, either on or off list? Regards Mike Dell Networking Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8367 8501 E-mail: mike.dell@dataconnection.com Web: http://www.dataconnection.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: 16 April 2004 22:21 To: idr@ietf.org Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, During the Last Call it would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 13:36:09 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. - ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - - --OtherAccess-- - - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ 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 (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23379 for ; Wed, 28 Apr 2004 13:02:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCF-0005JQ-7g; Wed, 28 Apr 2004 12:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs5E-0003VI-5s for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:38:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27230 for ; Wed, 28 Apr 2004 12:38:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs5B-0005XF-5a for idr@ietf.org; Wed, 28 Apr 2004 12:38:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs4F-0005VW-00 for idr@ietf.org; Wed, 28 Apr 2004 12:37:51 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIs3Q-0005S5-00 for idr@ietf.org; Wed, 28 Apr 2004 12:37:00 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 58EFB2D485B for ; Wed, 28 Apr 2004 12:36:26 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 75082-01-13 for ; Wed, 28 Apr 2004 12:36:14 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3FB802D4869 for ; Wed, 28 Apr 2004 12:36:14 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00 Message-ID: Thread-Topic: [Idr] draft-keyur-prefixlimit-orf-00 Thread-Index: AcQtOGqpfZ3Y41LETMSRslIG2LgcpAABdwRQ From: "Susan Hares" To: "John G. Scudder" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 28 Apr 2004 12:36:14 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA23379 John: Well this is amazing. Since you suggested the complexity... Perhaps you changed your mind. We put the complex ORF policy in because you state Cisco did not support dynamic configuration. In simplifying this, I do not find people wanting to go to an ORF policy. Sue PS - your acknowledgement section is problematic. -----Original Message----- From: John G. Scudder [mailto:jgs@cisco.com] Sent: Wednesday, April 28, 2004 11:19 AM To: idr@ietf.org Subject: [Idr] draft-keyur-prefixlimit-orf-00 Folks, As others have noted, while the underlying goal of draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the actual mechanisms proposed are more complex than is necessary. We've written another draft which we think provides the needed functionality with less complexity, along the lines of what I suggested at the meeting in Minneapolis. In summary we introduce a new ORF-type which carries a 32 bit prefix limit, and also use the PERMIT/DENY flag to signal whether enforcement of the limit will be done by dropping the session or not. The draft is a tad over four pages plus six pages of IETF boilerplate. The draft has been submitted as an I-D. Until it's available in the usual places, you can find it at ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt Discussion of the draft would be welcome. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21485 for ; Wed, 28 Apr 2004 12:28: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 1BIrm1-0007zA-2F; Wed, 28 Apr 2004 12:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrVA-00034W-30 for idr@optimus.ietf.org; Wed, 28 Apr 2004 12:01:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24513 for ; Wed, 28 Apr 2004 12:01:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrV7-0002rD-KP for idr@ietf.org; Wed, 28 Apr 2004 12:01:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrUB-0002lt-00 for idr@ietf.org; Wed, 28 Apr 2004 12:00:36 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BIrTF-0002cf-00 for idr@ietf.org; Wed, 28 Apr 2004 11:59:37 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWW00MB71JSW5@firewall.mci.com> for idr@ietf.org; Wed, 28 Apr 2004 15:55:04 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWW00B011GDNE@pmismtp04.mcilink.com>; Wed, 28 Apr 2004 15:55:04 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWW00A4Z1JCP8@pmismtp04.mcilink.com>; Wed, 28 Apr 2004 15:54:49 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] Soft-Notify as an IDR WG document In-reply-to: To: "'Pekka Savola'" , "'Gargi Nalawade'" Cc: "'Pedro Roque Marques'" , idr@ietf.org, "'Yakov Rekhter'" Message-id: <002601c42d39$22a08ef0$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 28 Apr 2004 11:54:48 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA21485 The response to this particular thread has been particularly interesting. So long the dominant story from this community has been to put all new services and new features on the existing BGP protocol, which has an established base, and keep the operator's world easy and simple. The argument was that the vendors were good enough to handle all the complexities in the protocol implementation and the operators need not worry about code issues as much. So the (over)loading of BGP continues. Some people, realizing that the BGP train was coming too fast and too strong, stopped arguing. Now, here is this thread, where a part of the same community is suggesting that giving individual soft control to each AFI/SAFI pair would make BGP protocol implementation more complicated than necessary and we should push the complexity to the operator world. That is fine and in some ways sane, but in most ways confusing. If the community has already made its mind that BGP is going to carry most of the services, the vendor community has accepted to undertake that incremental complexity and the operators have accepted to live with the risk, then resisting this draft from going to WG, is a mixed signal. If everyone HAS to live with multiple AFI/SAFI in the same session, they might as well get their control and not think about how many sets of sessions they should run in their infrastructure. If the BGP session has to be split it should be split across the infrastructure and service boundary. The infrastructure layer should run hardened well tested BGP code and the service layer could run new loaded BGP (or ??) code which will have individual control of individual services built-in. -Parantap -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Pekka Savola Sent: Tuesday, April 27, 2004 6:17 AM To: Gargi Nalawade Cc: Pedro Roque Marques; idr@ietf.org; Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document On Mon, 26 Apr 2004, Gargi Nalawade wrote: > > I can come up w/ 2 simple scenarios: > > a) you want fate sharing... i.e. intentionally tie afis so that when > > one fails the other does fail also. (both are required to provide a > > service for instance). > > b) you don't want to deal w/ the extra complexity of monitoring > > multiple substates and prefer to deal w/ a binary "works" / "broken". > > > > In both these examples which i consider rather realistic adding > > notifications/negotiation does not provide value. > > Give me one Provider who says that because IPv4 Unicast in their network > is needed for providing some IPv4 Multicast service, IPv4 unicast should > fail whenever IPv4 Multicast has an error or a CEASE notification. And when would such an error occur? If you have shared unicast/multicast infrastructure, pretty much never, unless both would be equally impacted. And when the topologies aren't congruent, then you will notice it in any case. I share Pedro's concerns about the applicability. If operators see it important to protect AFI/SAFIs from each other, something like "multisession" seems like an obvious choice. If there is an obvious choice, it will be deployed as well. It seems like we're talking about a solution which would become interesting either in the scenario where 1) operator is not (sufficiently interested) for doing something like multi-session BGP (but could be interested in something like this), or 2) operator doesn't want to wait for multi-session, and wants something sooner. Both of these scenarios seem very questionable to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19348 for ; Wed, 28 Apr 2004 11:50:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr1e-00023Z-LE; Wed, 28 Apr 2004 11:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqt7-0000C9-2q for idr@optimus.ietf.org; Wed, 28 Apr 2004 11:22:17 -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 LAA21172 for ; Wed, 28 Apr 2004 11:22:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqt4-0006Si-TT for idr@ietf.org; Wed, 28 Apr 2004 11:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqs6-0006OU-00 for idr@ietf.org; Wed, 28 Apr 2004 11:21:15 -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 1BIqr6-0006HO-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 07:31:38 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFJgW9008270; Wed, 28 Apr 2004 08:19:42 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06341; Wed, 28 Apr 2004 11:19:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200404151359.i3FDxsJ92103@merlot.juniper.net> References: <200404151359.i3FDxsJ92103@merlot.juniper.net> To: Yakov Rekhter From: "John G. Scudder" Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 28 Apr 2004 11:19:59 -0400 (Following up to original thread for completeness.) I don't think that the draft as it stands is appropriate as a WG doc because it's rather too complex. As noted in my other message, we've submitted another draft, draft-keyur-prefixlimit-orf-00, which represents an alternative approach to achieving the same goals. Regards, --John At 6:59 AM -0700 4/15/04, Yakov Rekhter wrote: >Folks, > >We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt >as an IDR WG document. Please send comments to the list. The deadline >for comments is April 29, 2004. > >Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19262 for ; Wed, 28 Apr 2004 11:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr1d-00023B-HX; Wed, 28 Apr 2004 11:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqsH-0008Uv-0n for idr@optimus.ietf.org; Wed, 28 Apr 2004 11:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21161 for ; Wed, 28 Apr 2004 11:21:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqsE-0006PI-Pj for idr@ietf.org; Wed, 28 Apr 2004 11:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqrL-0006Lg-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:28 -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 1BIqr5-0006HO-00 for idr@ietf.org; Wed, 28 Apr 2004 11:20:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 07:31:36 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFJeW9008210 for ; Wed, 28 Apr 2004 08:19:41 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-252.cisco.com [64.101.214.252]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06338 for ; Wed, 28 Apr 2004 11:19:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-keyur-prefixlimit-orf-00 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, 28 Apr 2004 11:19:27 -0400 Folks, As others have noted, while the underlying goal of draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the actual mechanisms proposed are more complex than is necessary. We've written another draft which we think provides the needed functionality with less complexity, along the lines of what I suggested at the meeting in Minneapolis. In summary we introduce a new ORF-type which carries a 32 bit prefix limit, and also use the PERMIT/DENY flag to signal whether enforcement of the limit will be done by dropping the session or not. The draft is a tad over four pages plus six pages of IETF boilerplate. The draft has been submitted as an I-D. Until it's available in the usual places, you can find it at ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt Discussion of the draft would be welcome. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27413 for ; Tue, 27 Apr 2004 11:24: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 1BIUIY-0001LJ-MT; Tue, 27 Apr 2004 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUGd-0000ws-3D for idr@optimus.ietf.org; Tue, 27 Apr 2004 11:13:03 -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 LAA06409 for ; Tue, 27 Apr 2004 11:13:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUGa-0004oM-5o for idr@ietf.org; Tue, 27 Apr 2004 11:13:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUFg-0004lK-00 for idr@ietf.org; Tue, 27 Apr 2004 11:12:05 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BIUEr-0004ej-00 for idr@ietf.org; Tue, 27 Apr 2004 11:11:13 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3RFAfBm020811; Tue, 27 Apr 2004 08:10:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RFAfJ73229; Tue, 27 Apr 2004 08:10:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271510.i3RFAfJ73229@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Your message of "Thu, 22 Apr 2004 12:44:26 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42644.1083078641.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 27 Apr 2004 08:10:41 -0700 Pekka, > On Fri, 16 Apr 2004, Yakov Rekhter wrote: > > During the Last Call it would be greatly appreciated if folks would > > read the document and comment on it to the IDR mailing list. In > > other words, we need "yes, looks good" or "should fix this and > > that", not just silence. > > In general, I think this should be rather close to being ready for > going forward. > > A few quick comments: > > - the text could use a lot more updates, but is readable as it is. > > - where are the implementation & interop reports? Enke is working on it (see his e-mail to the IDR mailing list on 4/14/2004). > - several ID-nits or other process issues must be fixed, at least: > o Status of this memo, Abstract, etc. must be unnumbered sections > (typically Introduction is section number 1) ok. > o No references in the abstract. ok. > o One cannot have normative references to documents of lower > maturity level. I suggest moving everything except [1] (or > maybe also [7]) to a new Informational References section. Correct - [1] should go into the Normative Reference section, the rest should go into the Non-normative Reference section. > o The document should probably say (in Abstract and Introduction) > that this document Obsoletes both 2796 and 1966 (note 2796 only > Updates 1966, which was probably a bug.)? Ok. > o Standard IPR statement is needed at the end even if there is is no > IPR. The date in the copyright statement is 4 years old as well.. ok. > o every empty line in this memo is duplicated (due to flawed > DOS/WINDOWS -> Unix conversion?) ok. > - food for thought: should we kill two birds in one stone, and also > declare RFC1863 ("A BGP/IDRP Route Server alternative to a full > mesh routing") historic? Is that useful anymore? This is a good question. May I suggest you'll bring it up to the IDR mailing list after we'll finish the WG Last Call on this document (as it deserves discussion on its own). > - A few rewordings I spotted (I grew bored with the text soon after > the abstract, as there would have been a lot of changes): > > Currently in the Internet BGP > deployments are configured such that that all BGP speakers within a > single AS must be fully meshed so that any external routing > information must be re-distributed to all other routers within that > AS. > > ==> s/Currently in the Internet BGP deployments are configured such > that that/Typically/ (the same in the Introduction) > > information, as is common in many of todays internet networks. > > ==> s/todays internet/today's Internet/ Sure. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA24510 for ; Tue, 27 Apr 2004 10:32: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 1BITY5-0008B8-Kv; Tue, 27 Apr 2004 10: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 1BITRH-00064e-4T for idr@optimus.ietf.org; Tue, 27 Apr 2004 10:19:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03319 for ; Tue, 27 Apr 2004 10:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITRA-00024l-Sz for idr@ietf.org; Tue, 27 Apr 2004 10:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITQE-00022g-00 for idr@ietf.org; Tue, 27 Apr 2004 10:18:54 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BITPL-0001yt-00 for idr@ietf.org; Tue, 27 Apr 2004 10:18:00 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9722F2D4836 for ; Tue, 27 Apr 2004 10:17:27 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36326-01-26 for ; Tue, 27 Apr 2004 10:17:15 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5FDF72D481B for ; Tue, 27 Apr 2004 10:17:15 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQsWiIwjxNZgRFGRyCV7JJGht496AACB2XA From: "Susan Hares" To: "Yakov Rekhter" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 27 Apr 2004 10:17:15 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA24510 Narrowing down to one would be fine. Sue -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Tuesday, April 27, 2004 9:18 AM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Sue, If one uses ORF to pass prefix limit, then I think there is no need to also exchange this limit in the BGP Open message - all you need to carry in the Open message is the Capability that indicates support for the prefix limit ORF type (and the appropriate AFI/SAFI). This is because of the way how ORF operates (quoting from the ORF spec): Consider a BGP speaker that advertises the Cooperative Route Filtering Capability indicating its willingness to receive a particular set of from its peer, and that receives the Cooperative Route Filtering Capability indicating the desire of the peer to send a particular set to the speaker. If for a given the intersection between these two sets are not-empty, the speaker SHOULD NOT advertise to the peer any routes with that prior to receiving from the peer any ROUTE-REFRESH message carrying that , where the message could be either without any ORF entries, or with one or more ORF entry and When-to-refresh field set to IMMEDIATE. If, on the other hand, for a given the intersection between these two sets is empty, the speaker SHOULD follow normal BGP procedures. In the above pay especial attention to the "speaker SHOULD NOT advertise" part. I am also a bit concerned with support for two ways of advertising the prefix limit: one via OFR and another via Dynamic Capabilities. Why narrowing this down to one is not enough ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA21820 for ; Tue, 27 Apr 2004 09:46: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 1BISqX-0003hh-9n; Tue, 27 Apr 2004 09:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISjh-0002XB-J8 for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:34:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00253 for ; Tue, 27 Apr 2004 09:34:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISjb-0007a3-Vg for idr@ietf.org; Tue, 27 Apr 2004 09:34:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISij-0007Xr-00 for idr@ietf.org; Tue, 27 Apr 2004 09:33:57 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BISiQ-0007WB-00 for idr@ietf.org; Tue, 27 Apr 2004 09:33:38 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3RDX8Bm020529; Tue, 27 Apr 2004 06:33:08 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RDX8J64920; Tue, 27 Apr 2004 06:33:08 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271333.i3RDX8J64920@merlot.juniper.net> To: Michael Dell cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: Your message of "Tue, 27 Apr 2004 14:20:55 BST." <53F74F5A7B94D511841C00B0D0AB16F802B138F3@baker.datcon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30635.1083072787.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 27 Apr 2004 06:33:07 -0700 Mike, > Yakov > > I have no particular comments on or issues with the draft. However, we were > slightly surprised by the time difference between this draft being published > and then moving to last call - about 2 minutes by my count. I can't see any > details on what is motivating this draft in the proceedings of the last > couple of IETF meetings. > > Apologies if I'm the only reader of this list that doesn't know the history > behind this modification, but perhaps you could summarise for me, either on > or off list? The main purpose of this draft is to update the current BGP Route Reflector spec to document how BGP route selection is done in the presence of BGP Route Reflectors. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA21108 for ; Tue, 27 Apr 2004 09:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISa6-0001BA-2o; Tue, 27 Apr 2004 09:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISVD-0000He-Up for idr@optimus.ietf.org; Tue, 27 Apr 2004 09:20:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29379 for ; Tue, 27 Apr 2004 09:19:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISV8-00051r-Fc for idr@ietf.org; Tue, 27 Apr 2004 09:19:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISUI-0004oJ-00 for idr@ietf.org; Tue, 27 Apr 2004 09:19:02 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BISTY-0004MK-00 for idr@ietf.org; Tue, 27 Apr 2004 09:18:16 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3RDHkl66515; Tue, 27 Apr 2004 06:17:46 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3RDHfJ63618; Tue, 27 Apr 2004 06:17:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404271317.i3RDHfJ63618@merlot.juniper.net> To: "Susan Hares" cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Your message of "Mon, 26 Apr 2004 13:53:43 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28916.1083071861.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 27 Apr 2004 06:17:41 -0700 Sue, If one uses ORF to pass prefix limit, then I think there is no need to also exchange this limit in the BGP Open message - all you need to carry in the Open message is the Capability that indicates support for the prefix limit ORF type (and the appropriate AFI/SAFI). This is because of the way how ORF operates (quoting from the ORF spec): Consider a BGP speaker that advertises the Cooperative Route Filtering Capability indicating its willingness to receive a particular set of from its peer, and that receives the Cooperative Route Filtering Capability indicating the desire of the peer to send a particular set to the speaker. If for a given the intersection between these two sets are not-empty, the speaker SHOULD NOT advertise to the peer any routes with that prior to receiving from the peer any ROUTE-REFRESH message carrying that , where the message could be either without any ORF entries, or with one or more ORF entry and When-to-refresh field set to IMMEDIATE. If, on the other hand, for a given the intersection between these two sets is empty, the speaker SHOULD follow normal BGP procedures. In the above pay especial attention to the "speaker SHOULD NOT advertise" part. I am also a bit concerned with support for two ways of advertising the prefix limit: one via OFR and another via Dynamic Capabilities. Why narrowing this down to one is not enough ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA11485 for ; Tue, 27 Apr 2004 06:40:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPor-00007v-Kd; Tue, 27 Apr 2004 06:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPh3-0007Io-4M for idr@optimus.ietf.org; Tue, 27 Apr 2004 06:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19890 for ; Tue, 27 Apr 2004 06:19:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPgz-0002xy-9A for idr@ietf.org; Tue, 27 Apr 2004 06:19:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPg2-0002lI-00 for idr@ietf.org; Tue, 27 Apr 2004 06:18:58 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIPf9-0002Lj-00 for idr@ietf.org; Tue, 27 Apr 2004 06:18:03 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3RAGYF13177; Tue, 27 Apr 2004 13:16:34 +0300 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , , Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408DB470.4090505@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 27 Apr 2004 13:16:34 +0300 (EEST) On Mon, 26 Apr 2004, Gargi Nalawade wrote: > > I can come up w/ 2 simple scenarios: > > a) you want fate sharing... i.e. intentionally tie afis so that when > > one fails the other does fail also. (both are required to provide a > > service for instance). > > b) you don't want to deal w/ the extra complexity of monitoring > > multiple substates and prefer to deal w/ a binary "works" / "broken". > > > > In both these examples which i consider rather realistic adding > > notifications/negotiation does not provide value. > > Give me one Provider who says that because IPv4 Unicast in their network > is needed for providing some IPv4 Multicast service, IPv4 unicast should > fail whenever IPv4 Multicast has an error or a CEASE notification. And when would such an error occur? If you have shared unicast/multicast infrastructure, pretty much never, unless both would be equally impacted. And when the topologies aren't congruent, then you will notice it in any case. I share Pedro's concerns about the applicability. If operators see it important to protect AFI/SAFIs from each other, something like "multisession" seems like an obvious choice. If there is an obvious choice, it will be deployed as well. It seems like we're talking about a solution which would become interesting either in the scenario where 1) operator is not (sufficiently interested) for doing something like multi-session BGP (but could be interested in something like this), or 2) operator doesn't want to wait for multi-session, and wants something sooner. Both of these scenarios seem very questionable to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA01442 for ; Tue, 27 Apr 2004 03:39:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN3a-0007q3-QL; Tue, 27 Apr 2004 03:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN0G-0007Ch-Of for idr@optimus.ietf.org; Tue, 27 Apr 2004 03:27: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 DAA10697 for ; Tue, 27 Apr 2004 03:27:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIN0E-0000ES-IG for idr@ietf.org; Tue, 27 Apr 2004 03:27:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMzK-00002V-00 for idr@ietf.org; Tue, 27 Apr 2004 03:26:43 -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 1BIMya-0007VO-00 for idr@ietf.org; Tue, 27 Apr 2004 03:25:56 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 23:38:18 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R7PPW9021215; Tue, 27 Apr 2004 00:25:25 -0700 (PDT) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL66492; Tue, 27 Apr 2004 00:24:35 -0700 (PDT) Message-ID: <408E0AE0.4090701@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org CC: Pedro Roque Marques , gargi@cisco.com, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> In-Reply-To: <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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, 27 Apr 2004 00:25:20 -0700 All, > The deployment part of the equation doesn't... > Ops people understand the bgp state machine... its easy to add the > concept of multisession on top. Its is a much more significant > chalenge to add this per nlri up/down negotiation. Yes I agree that soft notify adds a new layer of troubleshooting & deployment complexity. While today most of the monitoring tools or SNMP work on a per session granularity it would require to be immediately updated to go deeper to the AFI/SAFI per session levels. Otherwise operators may have a really hard time to monitor what is going on. And unless they know that one AFI/SAFI is down under a working BGP session their NOC can't log in and fix the problem hence end customers may be impacted. Maybe it goes without saying that modifications to a number of show commands would be also required. On the other hand what is not clear to me is why do we equate Soft-Notify to address just the session reset piece. For whatever it is worth my observations of various BGP deployments today lead me to believe that BGP code in most implementations does not trigger session Notifications in the first place that often ;). So I am not sure if we are solving a real problem here. And the problem at hand should be solved with the simplest solution so multisession seems to fit the bill. Moreover multisession seems to be an automation to today's manual session separation which some operators are already using. That said I think one could observe that Soft-Notify does not just address the reset problem. Well maybe the name of the draft is wrong :) The functionality I support in it is to inform the peer about some BGP actions or events without resetting the session. As original INFORM draft was proposing and very similar to what Enke's cease msg defines for the Notification itself. Just an real live example ... BGP draft says: A BGP speaker MAY support the ability to impose an (locally config- ured) upper bound on the number of address prefixes the speaker is willing to accept from a neighbor. When the upper bound is reached, the speaker (under control of local configuration) either (a) dis- cards new address prefixes from the neighbor (while maintaining BGP connection with the neighbor), or (b) terminates the BGP connection with the neighbor. If the BGP speaker decides to terminate its BGP connection with a neighbor because the number of address prefixes received from the neighbor exceeds the locally configured upper bound, then the speaker MUST send to the neighbor a NOTIFICATION mes- sage with the Error Code Cease. The speaker MAY also log this locally. So in the case operator choose to select option (a) above his EBGP peer has no way of knowing about action of his peer. So maybe a good approach would be to reword the draft to primarily deliver the BGP event messaging between peers not causing the session resets while still allowing an optional vendor specific pool of msg types. Therefor market and operators could decide which messages/actions are useful and which not ... In that light I would support to accept the reworded draft as an IDR WG doc. R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA28612 for ; Tue, 27 Apr 2004 02:52:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIML1-0001zO-Nq; Tue, 27 Apr 2004 02:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMFp-0000ty-Du for idr@optimus.ietf.org; Tue, 27 Apr 2004 02:39:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07818 for ; Tue, 27 Apr 2004 02:39:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMFl-0006zg-L1 for idr@ietf.org; Tue, 27 Apr 2004 02:39:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMEq-0006pq-00 for idr@ietf.org; Tue, 27 Apr 2004 02:38:41 -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 1BIME0-0006W0-00 for idr@ietf.org; Tue, 27 Apr 2004 02:37:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 22:50:10 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R6bGW9016203; Mon, 26 Apr 2004 23:37:17 -0700 (PDT) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL64644; Mon, 26 Apr 2004 23:36:28 -0700 (PDT) Message-ID: <408DFF99.7060601@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John G. Scudder" CC: idr@ietf.org Subject: Re: [Idr] Multisession as WG doc References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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, 26 Apr 2004 23:37:13 -0700 I support multisession draft to become an IDR WG doc. R. > John G. Scudder wrote: > > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working > group document. > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA10199 for ; Mon, 26 Apr 2004 21:26:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHJP-0002i2-8A; Mon, 26 Apr 2004 21:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHF9-0001tJ-4b for idr@optimus.ietf.org; Mon, 26 Apr 2004 21:18:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08098 for ; Mon, 26 Apr 2004 21:18:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHF6-0001s4-Gs for idr@ietf.org; Mon, 26 Apr 2004 21:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHEL-0001mO-00 for idr@ietf.org; Mon, 26 Apr 2004 21:17:50 -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 1BIHDi-0001eA-00 for idr@ietf.org; Mon, 26 Apr 2004 21:17:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 17:29:28 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3R1GXSu007661; Mon, 26 Apr 2004 18:16:38 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL51033; Mon, 26 Apr 2004 18:15:46 -0700 (PDT) Message-ID: <408DB470.4090505@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 18:16:32 -0700 > No, sub-states within a bgp session do not exist. A session is either > working w/ all the functionality that has been configured on it, or > its is not. This is an implementation-specific design choice. >>That too, not always. Note that even with >>Multisession, multiple afi/safis can share the same session. > > That doesnt mean that multisession can't be used w/ 1 session per > nlri... in fact it allows you to control exactly what granularity is > desired. Exactly. It also does not mean that it always mandates running one afi/safi per session, which brings us back to today's BGP spec. So lets just talk about that. > > >>Soft-notify is aimed at addressing the case when multiple afi/safi's >>share one session > > and why would you do that *and* want per nlri mgmt of the session ??? Soft-notify does not need per-nlri "session"management. Whatever management is needed - the state-machine and infra for that already exists post- MP_REACH. Unless some implementation has limittaions, in which case it is for that implementation to fix. > The deployment part of the equation doesn't... > Ops people understand the bgp state machine... its easy to add the > concept of multisession on top. Its is a much more significant > chalenge to add this per nlri up/down negotiation. I dont see any per nlri negotiation challenges. The mechanism exists today and it works. >>For those cases, the draft proposes using Notifications instead of >>Soft-Notifications. > > > Which doesnt provide fault containment. I'd rather have a single way > of fault containment that works across all reasons for session > failure... For session-failures yes. But theer are errors such as CEASE which should not require a session-failure as they are independent of that. > > Why don't we consider the reasons why one would like to have different > afi/safi pairs in the same session and then ask ourselfs what having > indepent notifications/up events will buy you. Reduced #sessions, avoid session reestab latency (we are after all limited by the speed of light :)), reduced overhead in terms of resources that need to be allocated per-session and so on.. > > I can come up w/ 2 simple scenarios: > a) you want fate sharing... i.e. intentionally tie afis so that when > one fails the other does fail also. (both are required to provide a > service for instance). > b) you don't want to deal w/ the extra complexity of monitoring > multiple substates and prefer to deal w/ a binary "works" / "broken". > > In both these examples which i consider rather realistic adding > notifications/negotiation does not provide value. Give me one Provider who says that because IPv4 Unicast in their network is needed for providing some IPv4 Multicast service, IPv4 unicast should fail whenever IPv4 Multicast has an error or a CEASE notification. I dont think these are realistic scenarios. However, thank you for your opinion. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA08042 for ; Mon, 26 Apr 2004 20:48: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 1BIGhf-0006Pp-JP; Mon, 26 Apr 2004 20:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIGeB-00060d-QA for idr@optimus.ietf.org; Mon, 26 Apr 2004 20:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06429 for ; Mon, 26 Apr 2004 20:40:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIGe9-0005uc-H7 for idr@ietf.org; Mon, 26 Apr 2004 20:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGdI-0005nD-00 for idr@ietf.org; Mon, 26 Apr 2004 20:39:32 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIGcH-0005Zr-00 for idr@ietf.org; Mon, 26 Apr 2004 20:38:29 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3R0bq5O020467; Mon, 26 Apr 2004 17:37:52 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3R0bqKi020464; Mon, 26 Apr 2004 17:37:52 -0700 (PDT) Message-Id: <200404270037.i3R0bqKi020464@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D9F73.1020906@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> <408D9F73.1020906@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 17:37:52 -0700 (PDT) Gargi Nalawade writes: > Pedro Roque Marques wrote: >> Gargi Nalawade writes: >> > >>Not really. The soft-notofication does not affcet the number of > >>objects being tracked etc. Everything else stays exactly the > >>same. >> >> >> That is an unrealistic claim.. The network operator needs to know >> that a given set of functionality is working. If you split a set >> (session) such that parts can fail independently that needs to be >> monitored. > This already exists today. Look at how Route-refresh for a > particular afi/safi works today. This is no different. Unless of > course there are implementation-specific issues. No, sub-states within a bgp session do not exist. A session is either working w/ all the functionality that has been configured on it, or its is not. > Lets not mix this with multisession. That is a different solution > with different tradeoffs. Let us talk about Soft-notify here, so we > can focus the discussion on the pros & cons of this one. Lets not. What is relavant is to address a particular problem and to consider what option to chose we must contrast several approaches. >> If you believe you want to manage things with per nlri-type >> granularity you can do it w. multisession. > Which is a different way of doing it by forcing each afi/safi on a > separate session. so you do agree that multisession is a different way to solve the problem. > That too, not always. Note that even with > Multisession, multiple afi/safis can share the same session. That doesnt mean that multisession can't be used w/ 1 session per nlri... in fact it allows you to control exactly what granularity is desired. > Soft-notify is aimed at addressing the case when multiple afi/safi's > share one session and why would you do that *and* want per nlri mgmt of the session ??? >> Besides multisession is 10x easier to implement and deploy since it >> can use existing state machines. > Depends on the implementation :) The deployment part of the equation doesn't... Ops people understand the bgp state machine... its easy to add the concept of multisession on top. Its is a much more significant chalenge to add this per nlri up/down negotiation. >> Like update errors which more likely than not corrupt the tcp >> stream. > For those cases, the draft proposes using Notifications instead of > Soft-Notifications. Which doesnt provide fault containment. I'd rather have a single way of fault containment that works across all reasons for session failure... >> Please explain what can be done w. this approach that cannot be >> done w/ one session per afi/safi or why, given that we are talking >> about a significant development and deployment (given mgmt impact), >> this approach is better than using 1 session per afi/safi. > The point is not to force all afi/safi's on a single session. But you haven't explained why that should be a goal... > The > solution-space addressed by this document is the existing > deployments and the existing BGP-Spec where operators either have or > may choose to have multiple afi/safi's on a single session. Why don't we consider the reasons why one would like to have different afi/safi pairs in the same session and then ask ourselfs what having indepent notifications/up events will buy you. I can come up w/ 2 simple scenarios: a) you want fate sharing... i.e. intentionally tie afis so that when one fails the other does fail also. (both are required to provide a service for instance). b) you don't want to deal w/ the extra complexity of monitoring multiple substates and prefer to deal w/ a binary "works" / "broken". In both these examples which i consider rather realistic adding notifications/negotiation does not provide value. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05092 for ; Mon, 26 Apr 2004 19:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFrO-0007xC-EM; Mon, 26 Apr 2004 19:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFql-0007ot-Vh for idr@optimus.ietf.org; Mon, 26 Apr 2004 19:49: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 TAA04227 for ; Mon, 26 Apr 2004 19:49:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIFqk-0001bm-5W for idr@ietf.org; Mon, 26 Apr 2004 19:49:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFpo-0001Xc-00 for idr@ietf.org; Mon, 26 Apr 2004 19:48:25 -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 1BIFoy-0001Oa-00 for idr@ietf.org; Mon, 26 Apr 2004 19:47:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 15:59:49 +0000 Received: from cisco.com ([128.107.177.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QNl0W9015475; Mon, 26 Apr 2004 16:47:00 -0700 (PDT) Message-ID: <408D9F73.1020906@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.82] X-PMX-Version: 4.5.0.92886 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 16:46:59 -0700 Pedro Roque Marques wrote: > Gargi Nalawade writes: > >>Not really. The soft-notofication does not affcet the number of >>objects being tracked etc. Everything else stays exactly the >>same. > > > That is an unrealistic claim.. > The network operator needs to know that a given set of functionality > is working. If you split a set (session) such that parts can fail > independently that needs to be monitored. This already exists today. Look at how Route-refresh for a particular afi/safi works today. This is no different. Unless of course there are implementation-specific issues. > Again, you can achieve all this in a much simpler way by using > multisession, with variable degrees of granularity. Lets not mix this with multisession. That is a different solution with different tradeoffs. Let us talk about Soft-notify here, so we can focus the discussion on the pros & cons of this one. > We are talking about fate-sharing of different afi/safi in a given > session. Its is the exact same issue. Which is as per the BGP-Spec as it exists today. > If you believe you want to manage things with per nlri-type > granularity you can do it w. multisession. Which is a different way of doing it by forcing each afi/safi on a separate session. That too, not always. Note that even with Multisession, multiple afi/safis can share the same session. Soft-notify is aimed at addressing the case when multiple afi/safi's share one session and it is desirable that operations/events in one afi/safi do not affect the operation of the others on the same session as itself. > Besides multisession is 10x easier to implement and deploy since it > can use existing state machines. Depends on the implementation :) >>>you describe plus issues that you do not address. >> > >>Like which ones? > > > Like update errors which more likely than not corrupt the tcp > stream. For those cases, the draft proposes using Notifications instead of Soft-Notifications. > > Please explain what can be done w. this approach that cannot be done > w/ one session per afi/safi or why, given that we are talking about a > significant development and deployment (given mgmt impact), this > approach is better than using 1 session per afi/safi. The point is not to force all afi/safi's on a single session. The solution-space addressed by this document is the existing deployments and the existing BGP-Spec where operators either have or may choose to have multiple afi/safi's on a single session. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01305 for ; Mon, 26 Apr 2004 18:45:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEik-0006A9-4h; Mon, 26 Apr 2004 18:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEdD-0005QS-PX for idr@optimus.ietf.org; Mon, 26 Apr 2004 18:31: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 SAA00296 for ; Mon, 26 Apr 2004 18:31:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEdA-0002q9-Qy for idr@ietf.org; Mon, 26 Apr 2004 18:31:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEcF-0002md-00 for idr@ietf.org; Mon, 26 Apr 2004 18:30:19 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIEbd-0002ge-00 for idr@ietf.org; Mon, 26 Apr 2004 18:29:41 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QMSx5O020276; Mon, 26 Apr 2004 15:28:59 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QMSxmk020273; Mon, 26 Apr 2004 15:28:59 -0700 (PDT) Message-Id: <200404262228.i3QMSxmk020273@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gargi Nalawade Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D87AB.7050509@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> <408D87AB.7050509@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 15:28:59 -0700 (PDT) Gargi Nalawade writes: > Not really. The soft-notofication does not affcet the number of > objects being tracked etc. Everything else stays exactly the > same. That is an unrealistic claim.. The network operator needs to know that a given set of functionality is working. If you split a set (session) such that parts can fail independently that needs to be monitored. > The afi/safi demarcation is as specified by the BGP Spec > today, Soft-Notify does not touch it. If you do, then that would be > an implementation limitation or issue. Changing the operational model for BGP sessions will add complexity in terms of management. It must be a conscious tradeoff. Again, you can achieve all this in a much simpler way by using multisession, with variable degrees of granularity. > >>If we are talking of >>changing BGP semantics as it exists today > that is a separate issue >>and independant of this document. This > document addresses the >>problem that exists with today's > semantics. It is important that we >>address today's reality of > today's BGP semantics and avoid >>penalizing the other afi/safis > that share the same session in case >>of errors/actions on any one > of them. We are talking about fate-sharing of different afi/safi in a given session. Its is the exact same issue. If you believe you want to manage things with per nlri-type granularity you can do it w. multisession. Besides multisession is 10x easier to implement and deploy since it can use existing state machines. >> you describe plus issues that you do not address. > Like which ones? Like update errors which more likely than not corrupt the tcp stream. Please explain what can be done w. this approach that cannot be done w/ one session per afi/safi or why, given that we are talking about a significant development and deployment (given mgmt impact), this approach is better than using 1 session per afi/safi. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA00528 for ; Mon, 26 Apr 2004 18:31: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 1BIESN-0003I2-0h; Mon, 26 Apr 2004 18:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEGJ-0005L6-0V for idr@optimus.ietf.org; Mon, 26 Apr 2004 18:07:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27986 for ; Mon, 26 Apr 2004 18:07:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEGG-0001Ff-6O for idr@ietf.org; Mon, 26 Apr 2004 18:07:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEFX-0001Ao-00 for idr@ietf.org; Mon, 26 Apr 2004 18:06:52 -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 1BIEEq-00012d-00 for idr@ietf.org; Mon, 26 Apr 2004 18:06:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 14:17:12 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QM5WW9020515; Mon, 26 Apr 2004 15:05:33 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL35433; Mon, 26 Apr 2004 15:04:45 -0700 (PDT) Message-ID: <408D87AB.7050509@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 15:05:31 -0700 Pedro Roque Marques wrote: > Gargi Nalawade writes: > > >>There are a large number of cases that are frequently hit >>eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) >>of a safi, etc where it is unnecessary to penalize other afi/safis >>that run on the same session. > > > How do you recover from those conditions ? notification is just 1/2 of > the problem... its isn't enought to address somethis partially. Pls read the draft. It describes how. >>Of course one could limit one afi/safi >>per session, but unless we change the BGP Spec to force one session >>per every afi/safi, the reality is going to be that multiple >>afi/safis would share a single session. > > > why is that ? with the multisession appoach you can give the operator > a pratical way to select the unit of cotainment that it desires. In which case you would still end up containing multiple afi/safis over one session. So we are back to square one. > > There of course trade-offs in such a choice, such as an increase in > the number of objects that need to be monitored from an ops point of > view, but the same issues do exist with what you a proposing. Not really. The soft-notofication does not affcet the number of objects being tracked etc. Everything else stays exactly the same. The afi/safi demarcation is as specified by the BGP Spec today, Soft-Notify does not touch it. If you do, then that would be an implementation limitation or issue. >>If we are talking of >>changing BGP semantics as it exists today that is a separate issue >>and independant of this document. This document addresses the >>problem that exists with today's semantics. It is important that we >>address today's reality of today's BGP semantics and avoid >>penalizing the other afi/safis that share the same session in case >>of errors/actions on any one of them. > > > You seem to be considering just a subset of the shared fate implied in > a bgp session, which btw isn't necessarly a bad thing. > The multisession approach seems to me to cover all the scenarios that Multisession and soft-notify are complementary solutions. The former aims at separating out at the session level and gives a way to automate establishing separate sessions per afi/safi. The latter addresses the problem with today's spec which allows operators to have one session carrying multiple afi/safi's, but penalizes the other safis in case of operations that require reetting of only that afi/safi. > you describe plus issues that you do not address. Like which ones? -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA29608 for ; Mon, 26 Apr 2004 18:14: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 1BIEEk-0004YA-Ay; Mon, 26 Apr 2004 18: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 1BIE7F-00007Y-6u for idr@optimus.ietf.org; Mon, 26 Apr 2004 17:58:17 -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 RAA26750 for ; Mon, 26 Apr 2004 17:58:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIE7C-0000Q8-E7 for idr@ietf.org; Mon, 26 Apr 2004 17:58:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE6H-0000LR-00 for idr@ietf.org; Mon, 26 Apr 2004 17:57:18 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BIE5N-0000FT-00 for idr@ietf.org; Mon, 26 Apr 2004 17:56:21 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QLtP5O020225; Mon, 26 Apr 2004 14:55:25 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QLtPpi020222; Mon, 26 Apr 2004 14:55:25 -0700 (PDT) Message-Id: <200404262155.i3QLtPpi020222@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gargi Nalawade Cc: idr@ietf.org, Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <408D79BE.9050203@cisco.com> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> <408D79BE.9050203@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 14:55:25 -0700 (PDT) Gargi Nalawade writes: > There are a large number of cases that are frequently hit > eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) > of a safi, etc where it is unnecessary to penalize other afi/safis > that run on the same session. How do you recover from those conditions ? notification is just 1/2 of the problem... its isn't enought to address somethis partially. > Of course one could limit one afi/safi > per session, but unless we change the BGP Spec to force one session > per every afi/safi, the reality is going to be that multiple > afi/safis would share a single session. why is that ? with the multisession appoach you can give the operator a pratical way to select the unit of cotainment that it desires. There of course trade-offs in such a choice, such as an increase in the number of objects that need to be monitored from an ops point of view, but the same issues do exist with what you a proposing. > If we are talking of > changing BGP semantics as it exists today that is a separate issue > and independant of this document. This document addresses the > problem that exists with today's semantics. It is important that we > address today's reality of today's BGP semantics and avoid > penalizing the other afi/safis that share the same session in case > of errors/actions on any one of them. You seem to be considering just a subset of the shared fate implied in a bgp session, which btw isn't necessarly a bad thing. The multisession approach seems to me to cover all the scenarios that you describe plus issues that you do not address. > Hence I propose that this be accepted as a WG document. I maintain my opposition. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27854 for ; Mon, 26 Apr 2004 17:43: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 1BIDa8-0001CR-4m; Mon, 26 Apr 2004 17:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDMo-0005pJ-J2 for idr@optimus.ietf.org; Mon, 26 Apr 2004 17:10:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23230 for ; Mon, 26 Apr 2004 17:10:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDMm-000498-9j for idr@ietf.org; Mon, 26 Apr 2004 17:10:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDLA-0003wn-00 for idr@ietf.org; Mon, 26 Apr 2004 17:08:36 -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 1BIDJO-0003Y9-00 for idr@ietf.org; Mon, 26 Apr 2004 17:06:47 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 13:19:02 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QL67WB014707; Mon, 26 Apr 2004 14:06:11 -0700 (PDT) Received: from cisco.com (gargi-u5.cisco.com [128.107.162.118]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL29223; Mon, 26 Apr 2004 14:05:20 -0700 (PDT) Message-ID: <408D79BE.9050203@cisco.com> From: Gargi Nalawade User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques , idr@ietf.org CC: Yakov Rekhter Subject: Re: [Idr] Soft-Notify as an IDR WG document References: <200404261501.i3QF1aJ01072@merlot.juniper.net> <200404261704.i3QH49xC019760@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 14:06:06 -0700 There are a large number of cases that are frequently hit eg. reaching a Max-prefix limit, admin shutdown, user reset (clear) of a safi, etc where it is unnecessary to penalize other afi/safis that run on the same session. Of course one could limit one afi/safi per session, but unless we change the BGP Spec to force one session per every afi/safi, the reality is going to be that multiple afi/safis would share a single session. If we are talking of changing BGP semantics as it exists today that is a separate issue and independant of this document. This document addresses the problem that exists with today's semantics. It is important that we address today's reality of today's BGP semantics and avoid penalizing the other afi/safis that share the same session in case of errors/actions on any one of them. Hence I propose that this be accepted as a WG document. -Gargi Pedro Roque Marques wrote: > Yakov Rekhter writes: > > >>Folks, Please comment on the attached. The deadline for comments is >>May 10. > > > I dont think this document should be accepted as a work-group > document. The unit of containment in bgp should be the session. We can > possibly have multiple sessions between a pair of systems either via > manual config or with the mecanism that Scudder is proposing. > > Attempting to reset a subset of the nlri is something that won't work > in a considerable number of cases and that adds a very significant > ammount of complexity to BGP. > > I would like to propose that the WG rejects this approach. > > > _______________________________________________ > 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 (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26551 for ; Mon, 26 Apr 2004 17:21: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 1BIDIi-0004bf-Ai; Mon, 26 Apr 2004 17:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDAx-0001YN-99 for idr@optimus.ietf.org; Mon, 26 Apr 2004 16:58:03 -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 QAA20695 for ; Mon, 26 Apr 2004 16:57:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDAv-00024x-8p for idr@ietf.org; Mon, 26 Apr 2004 16:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID1p-0000Uu-00 for idr@ietf.org; Mon, 26 Apr 2004 16:48:39 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1BICrm-0006FK-00 for idr@ietf.org; Mon, 26 Apr 2004 16:38:14 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QKbgTN010072; Mon, 26 Apr 2004 15:37:43 -0500 (CDT) From: Andrew Lange To: Pekka Savola , Pedro Roque Marques cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <7663189.1082986622@[192.168.5.191]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 13:37:02 -0700 Hi Pekka, > Why do we need this in the first place? To "standardize" commonly > used communities? To give the users more tools to mess up their > routing, or to allow the users to make the ISP's policy more complex? Here is some additional text for the introduction which, I hope, will answer your questions. There is a clear demand by BGP-savvy customers to have enhanced control over their route announcements. Today this demand is addressed by custom, complex and difficult to manage community policies. There is no consistency across providers, except for the NO_EXPORT well known community specified in RFC1997. There are more well-known communities for common policies specified in this document to help provide commonality and ease of maintenance. The current route policies required to provide enhanced BGP services are very cumbersome. The larger space provided in flexible communities, and the introduction of neighbor classes significantly ease the implementation and maintenance burdens for service providers. Service providers also often tag their data based on where and from whom they learned it (peer, customer, geographic origin). The flexible community, and the neighbor class application especially, make both assigning inbound communities and matching on outbound peers significantly easier and less error prone. In addition, community values today are simply too small and too rigidly defined to allow for the growth of the Internet. For example, encoding IPv6 address and an action to take on them is simply impossible. > A few nits: > - if EX-COMM doesn't support IPv6 addresses, and that is important > enough, the support MUST be added. EX-COMM is 8 octets. An IPv6 address is 16. As IPv6 deployments progress there will be a demand for encoding IPv6 addresses. > - it might make sense to switch the order of Length and "ASN" fields > for better alignment. Length could also include the ASN field. (Maybe > this would be a more typical TLV encoding?) This would be pretty simple to do. I had structured things the way they are to allow for a larger DATA Field to encode values. We would max out at 251 octets of data with the ASN field second. 251 is probably enough, and we would gain a slightly simpler header and more alignment with existing communities. Okay, I'll reorder those two fields. Andrew > On Wed, 21 Apr 2004, Pedro Roque Marques wrote: >> Yakov Rekhter writes: >> > Folks, It would be greatly appreciated if folks would read the >> > document and comment on it to the IDR mailing list. In other words, >> > we need "yes, looks good" or "should fix this and that", not just >> > silence. >> >> my recollection is that this draft has been discussed before and that >> the majority of the WG requested that encoding and applications of >> communities be kept separate. >> >> reclying the comments: it does appear that the propossed applications >> are possible w/ existing protocol support. The author recognises that >> some of those applications may or may not be a good idea given that >> they seem to impose on an ISP a set of policies which the ISP may or >> may not wish to provide... >> >> reading the document, it seems that the original comments are still >> relevant. >> >> i also believe that embeding ipv4 and ipv6 addresses into communities is >> not a feature... addresses don't make for very good identifiers given >> that they may change. >> >> Pedro. >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr >> > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26509 for ; Mon, 26 Apr 2004 17:21: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 1BIDDR-0003DB-QQ; Mon, 26 Apr 2004 17:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID82-0000P2-BD for idr@optimus.ietf.org; Mon, 26 Apr 2004 16:55: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 QAA20457 for ; Mon, 26 Apr 2004 16:54:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BID80-0001bY-9Z for idr@ietf.org; Mon, 26 Apr 2004 16:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICzF-0007kX-00 for idr@ietf.org; Mon, 26 Apr 2004 16:45:59 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BICoL-0005fy-00 for idr@ietf.org; Mon, 26 Apr 2004 16:34:41 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QKY9Fq013047; Mon, 26 Apr 2004 15:34:10 -0500 (CDT) From: Andrew Lange To: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document Message-ID: <7451304.1082986410@[192.168.5.191]> In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 13:33:30 -0700 This draft should be accepted by the WG. It provides a valuable mechanism for today's deployments where we have multiple NLRI in a single session. Andrew --On Monday, April 26, 2004 8:01 AM -0700 Yakov Rekhter wrote: > Folks, > > Please comment on the attached. The deadline for comments is > May 10. > > Yakov. > > ------- Forwarded Message > > Date: Tue, 20 Apr 2004 12:47:27 -0700 > From: Gargi Nalawade > To: idr@ietf.org > Subject: [Idr] Soft-Notify as IDR WG document > > Hi All, > > I would like to request that BGP Soft-Notify draft, > draft-nalawade-bgp-soft-notify-00.txt be accepted as > an IDR WG document. > > - -Gargi > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > > _______________________________________________ > 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 (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA20818 for ; Mon, 26 Apr 2004 15:38:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBpi-0000YI-Uq; Mon, 26 Apr 2004 15:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBj1-000832-NN for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:25:07 -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 PAA13092 for ; Mon, 26 Apr 2004 15:25:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBj0-0000xN-EH for idr@ietf.org; Mon, 26 Apr 2004 15:25:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBi4-0000va-00 for idr@ietf.org; Mon, 26 Apr 2004 15:24:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BIBhR-0000ru-00 for idr@ietf.org; Mon, 26 Apr 2004 15:23:29 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2004 12:23:00 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-33.cisco.com [10.86.242.33]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3QJMvYu022232; Mon, 26 Apr 2004 15:22:57 -0400 (EDT) From: "zafar ali" To: "'Yakov Rekhter'" , Subject: RE: [Idr] Soft-Notify as an IDR WG document Organization: Cisco Systems Message-ID: <000401c42bc3$e2045b90$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 26 Apr 2004 15:22:57 -0400 Hi, Yes, this document should be accepted as a WG ID. Thanks Regards... Zafar >-----Original Message----- >From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf >Of Yakov Rekhter >Sent: Monday, April 26, 2004 11:02 AM >To: idr@ietf.org >Subject: [Idr] Soft-Notify as an IDR WG document > > >Folks, > >Please comment on the attached. The deadline for comments is May 10. > >Yakov. > >------- Forwarded Message > >Date: Tue, 20 Apr 2004 12:47:27 -0700 >From: Gargi Nalawade >To: idr@ietf.org >Subject: [Idr] Soft-Notify as IDR WG document > >Hi All, > >I would like to request that BGP Soft-Notify draft, >draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG >document. > >- -Gargi > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > >------- End of Forwarded Message > > >_______________________________________________ >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 (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA20484 for ; Mon, 26 Apr 2004 15:31:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBju-0008Ef-Uh; Mon, 26 Apr 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBaZ-000601-5K for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:16:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12253 for ; Mon, 26 Apr 2004 15:16:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBaX-0000Sx-PN for idr@ietf.org; Mon, 26 Apr 2004 15:16:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBZe-0000OQ-00 for idr@ietf.org; Mon, 26 Apr 2004 15:15:26 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1BIBYr-0000Hj-00 for idr@ietf.org; Mon, 26 Apr 2004 15:14:37 -0400 Received: from [192.168.5.191] (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3QJE5Dm011281; Mon, 26 Apr 2004 14:14:06 -0500 (CDT) From: Andrew Lange To: Pedro Roque Marques , Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document Message-ID: <2671110.1082981630@[192.168.5.191]> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 12:13:50 -0700 Hi Pedro, Replies are inline. > my recollection is that this draft has been discussed before and that > the majority of the WG requested that encoding and applications of > communities be kept separate. This suggestion was brought up at the SF IETF meeting. There was no action taken to access if this was a majority opinion or not. If we look at the former communities documents (1997 or the ext-comms draft) an initial set of applications is also specified in those documents. The applications specified in this draft parallel the ones specified in 1997 and ext-comms, with a couple of additions (neighbor classes, prepend, announce_with). > reclying the comments: it does appear that the propossed applications > are possible w/ existing protocol support. The author recognises that > some of those applications may or may not be a good idea given that > they seem to impose on an ISP a set of policies which the ISP may or > may not wish to provide... > > reading the document, it seems that the original comments are still > relevant. Could you expand on this a little? As an operator at the time I wrote this, I included a proviso that says that operators MUST be able to turn things off that they do not wish to honor. The application that I think SPs will be cautious with is the ANNOUNCE_WITH option. Some providers will want to allow their customers to do this, but some may not. The basis for this proposal was community policies that providers were already painstakingly using in their networks. The policy actions in the flex comms draft makes those policies easier to express, implement and maintain in SP's networks. Examples would include easy sending of lists of ASNs for NO_EXPORT, neighbor-class functionality, etc. > i also believe that embeding ipv4 and ipv6 addresses into communities is > not a feature... addresses don't make for very good identifiers given > that they may change. Changing addresses can be an operational concern. However, this extends the options that exist for extended communities. You cannot send a IPv6 route-target without the ability to encode an IP address. There are also some tactical situations where a BGP-savvy customer would want to encode an IP address. For example one could wish to prepend to an east-coast peer for its routes to avoid a perceived problem on that peering link. So AS 100 ---- AS 200 ---- AS 100 | AS 5000 AS 5000 would announce to 200 a community where it would ask that a specific prefix or set of prefixes be prepended to AS 100's east-coast peer IP (or neighbor class, if those are configured). AS 200 would prepend, and some of the traffic would move over to the AS100-AS200 west coast link. Andrew _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA20194 for ; Mon, 26 Apr 2004 15:27:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBd7-0006ix-Fb; Mon, 26 Apr 2004 15:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBWa-0004Hk-31 for idr@optimus.ietf.org; Mon, 26 Apr 2004 15:12: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 PAA11752 for ; Mon, 26 Apr 2004 15:12:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBWY-0000D8-SK for idr@ietf.org; Mon, 26 Apr 2004 15:12:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBVj-0000BC-00 for idr@ietf.org; Mon, 26 Apr 2004 15:11:24 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BIBVF-00008Y-00 for idr@ietf.org; Mon, 26 Apr 2004 15:10:53 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 37D29798E6C; Mon, 26 Apr 2004 12:10:53 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17966-07; Mon, 26 Apr 2004 12:10:52 -0700 (PDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 585EA798E6A; Mon, 26 Apr 2004 12:10:52 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 8FA6A979C2; Mon, 26 Apr 2004 12:10:51 -0700 (PDT) To: "Susan Hares" Cc: "Pekka Savola" , enke@redback.com, "Yakov Rekhter" , idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message from "Susan Hares" of "Mon, 26 Apr 2004 13:53:43 EDT." From: Enke Chen Message-Id: <20040426191051.8FA6A979C2@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 26 Apr 2004 12:10:51 -0700 Hi, Sue: At the last IDR meeting, there were several suggestions about simplifying the spec.. One particular one (by jgs?) is to just advertise the prefix limit, something like . As a BGP speaker knows how many prefixes it has advertised to a particular peer, the received from a peer should be sufficient for a local BGP to take action (such as generate warning, stop advertisement, ...) *If* the prefix-limit advertisement is needed, I suggest that we take the approach of just advertising . The current draft is just too complicated for the feature. -- Enke > From: "Susan Hares" > To: "Pekka Savola" > Cc: "Yakov Rekhter" , > > > Pekka: > > Thanks for the input. Your vote is for=20 > the simple version.=20 > > Sue > > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, April 23, 2004 1:17 AM > To: Susan Hares > Cc: Yakov Rekhter; idr@ietf.org > Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > > On Thu, 15 Apr 2004, Susan Hares wrote: > > Can you clarify something here: > > 1) Your need - informing the remote peer of > > warning limits, stop receive limits, and drop limits > > and SNMP traps, logs etcs > >=20 > > is the basis for the draft. > > We don't really *need* this, because we're monitoring the number of > prefixes advertised by peers. If they go over the top, an alarm > sounds in the NOC. There is no need to inform the peer of the prefix > limits we use, as no prefixes should be dropped based on that, and if > they are, the peer has been badly misbehaving and deserves what it > got. > > Remember, if a peer advertises 100 prefixes, you don't set the prefix=20 > limits to 101 prefixes or even 110 prefixes, but probably something=20 > like 200 or 500 prefixes. > > Our threat model here is, "we want to stop peers from accidentally > advertising the whole Internet or a lot more routes than is normal to > us." > > I.e., a properly administered systems do not need this option. > > But I would not object to having a simple option if that's what others > see useful. I would object to creating a complex option, because that > seems to go too much beyond the cost/benefit curve for an option which > is not needed at all in the first place. > > > 2) Providers we talk to had 2 cases: > > =09 > > 1) creeping VPN prefix limits > > 2) dump of whole routing table > >=20 > > The need to treat the two differently. > > No, I think I disagree with this. Why would they have to be treated=20 > differently? It's the number of prefixes per peer that counts, not=20 > per AFI/SAFI etc. used, or the manner by which they're transmitted. > > You protect your gear at the edge of the network, from either your > peers or your customers (if you import their routes into VPN), so > distinguishing per VPN doesn't seem to be all that useful. > > > 3) Set until changed - that's the rub > >=20 > > The providers wanted to negotiate the capabilties and > > upgrade the capabilities without dropping the connect. > >=20 > > Is that what you mean as well? If so, could you comment > > on what is complex. > > Currently, adding prefix-limits does not drop a session, so it's=20 > required that sessions aren't dropped if the prefix-limits are changed=20 > either. That means that if prefix-limit negotiation is specified, it=20 > must not require a session reset, yes. > =20 > > History:=20 > > We started this out with capabilities on open, and dynamic > > capabilities. Due to some vendor's request to include other > > mechanism (ORF, Soft Notify) to support the dynamic features -=20 > > we added the rest. > >=20 > > Other service providers said, Love the function but could you > > do it by prefix lengths. =20 > >=20 > > In an effort to get something working for all these folks, > > we made these other features optional. =20 > >=20 > > What part don't you like? Cause everything you stated you wanted -- > > is the basic part of the initial draft? Did you dis-like the = > additions > > (ORF, Soft Notify) and or the optional sub-codes?=20 > > > > Do you think we should go back to the initial draft simplistic model? > > It seems to me that if dynamic capabilities is a required-to-implement > mechanism, soft-notify is useless or even problematic (what if you are > doing both?). Similarly, I fail to see any need for ORF (but > admittedly, I haven't looked at it much) or using prefix lengths. =20 > Those who would like to distinguish prefix length in the > prefix-limiter are probably confusing inbound policy with appropriate > prefix-limits. > > So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and=20 > compact to me. > > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA18603 for ; Mon, 26 Apr 2004 14:58: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 1BIB8B-0001CN-Vq; Mon, 26 Apr 2004 14:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIB2O-0008E0-Eu for idr@optimus.ietf.org; Mon, 26 Apr 2004 14:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09179 for ; Mon, 26 Apr 2004 14:41:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIB2L-0005x2-MZ for idr@ietf.org; Mon, 26 Apr 2004 14:41:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIB1R-0005sI-00 for idr@ietf.org; Mon, 26 Apr 2004 14:40:05 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BIB0W-0005lr-00 for idr@ietf.org; Mon, 26 Apr 2004 14:39:08 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3QIccl62501 for ; Mon, 26 Apr 2004 11:38:38 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3QIcXJ30288; Mon, 26 Apr 2004 11:38:33 -0700 (PDT) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i3QIcX859341; Mon, 26 Apr 2004 11:38:33 -0700 (PDT) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs From: Rahul Aggarwal To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> Message-ID: <20040426112015.I53161@sapphire.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 11:38:33 -0700 (PDT) On Mon, 26 Apr 2004, Yakov Rekhter wrote: > Folks, > > Please comment on the attached. The deadline for comments is > May 10. > I don't think this document should be accepted as a WG document. Resetting some of the nlris on the same session will not help in a several cases and adds complexity. Also such an attempt at partial recovery may lead to the session continuing to operate in a faulty/corrupted state. rahul > Yakov. > > ------- Forwarded Message > > Date: Tue, 20 Apr 2004 12:47:27 -0700 > From: Gargi Nalawade > To: idr@ietf.org > Subject: [Idr] Soft-Notify as IDR WG document > > Hi All, > > I would like to request that BGP Soft-Notify draft, > draft-nalawade-bgp-soft-notify-00.txt be accepted as > an IDR WG document. > > - -Gargi > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > > _______________________________________________ > 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 (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16396 for ; Mon, 26 Apr 2004 14:19:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAUW-0006BE-CG; Mon, 26 Apr 2004 14:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAKy-0002ml-IC for idr@optimus.ietf.org; Mon, 26 Apr 2004 13:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05894 for ; Mon, 26 Apr 2004 13:56:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAKw-0001yM-BO for idr@ietf.org; Mon, 26 Apr 2004 13:56:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAJz-0001ul-00 for idr@ietf.org; Mon, 26 Apr 2004 13:55:12 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAJH-0001ok-00 for idr@ietf.org; Mon, 26 Apr 2004 13:54:27 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0A7EB2D482F for ; Mon, 26 Apr 2004 13:53:57 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08652-01-2 for ; Mon, 26 Apr 2004 13:53:44 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 015CF2D4856 for ; Mon, 26 Apr 2004 13:53:44 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQo8jzx/1yEIpStQGC+uslHUvVWcQCxPDag From: "Susan Hares" To: "Pekka Savola" Cc: "Yakov Rekhter" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 26 Apr 2004 13:53:43 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA16396 Pekka: Thanks for the input. Your vote is for the simple version. Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Friday, April 23, 2004 1:17 AM To: Susan Hares Cc: Yakov Rekhter; idr@ietf.org Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document On Thu, 15 Apr 2004, Susan Hares wrote: > Can you clarify something here: > 1) Your need - informing the remote peer of > warning limits, stop receive limits, and drop limits > and SNMP traps, logs etcs > > is the basis for the draft. We don't really *need* this, because we're monitoring the number of prefixes advertised by peers. If they go over the top, an alarm sounds in the NOC. There is no need to inform the peer of the prefix limits we use, as no prefixes should be dropped based on that, and if they are, the peer has been badly misbehaving and deserves what it got. Remember, if a peer advertises 100 prefixes, you don't set the prefix limits to 101 prefixes or even 110 prefixes, but probably something like 200 or 500 prefixes. Our threat model here is, "we want to stop peers from accidentally advertising the whole Internet or a lot more routes than is normal to us." I.e., a properly administered systems do not need this option. But I would not object to having a simple option if that's what others see useful. I would object to creating a complex option, because that seems to go too much beyond the cost/benefit curve for an option which is not needed at all in the first place. > 2) Providers we talk to had 2 cases: > > 1) creeping VPN prefix limits > 2) dump of whole routing table > > The need to treat the two differently. No, I think I disagree with this. Why would they have to be treated differently? It's the number of prefixes per peer that counts, not per AFI/SAFI etc. used, or the manner by which they're transmitted. You protect your gear at the edge of the network, from either your peers or your customers (if you import their routes into VPN), so distinguishing per VPN doesn't seem to be all that useful. > 3) Set until changed - that's the rub > > The providers wanted to negotiate the capabilties and > upgrade the capabilities without dropping the connect. > > Is that what you mean as well? If so, could you comment > on what is complex. Currently, adding prefix-limits does not drop a session, so it's required that sessions aren't dropped if the prefix-limits are changed either. That means that if prefix-limit negotiation is specified, it must not require a session reset, yes. > History: > We started this out with capabilities on open, and dynamic > capabilities. Due to some vendor's request to include other > mechanism (ORF, Soft Notify) to support the dynamic features - > we added the rest. > > Other service providers said, Love the function but could you > do it by prefix lengths. > > In an effort to get something working for all these folks, > we made these other features optional. > > What part don't you like? Cause everything you stated you wanted -- > is the basic part of the initial draft? Did you dis-like the additions > (ORF, Soft Notify) and or the optional sub-codes? > > Do you think we should go back to the initial draft simplistic model? It seems to me that if dynamic capabilities is a required-to-implement mechanism, soft-notify is useless or even problematic (what if you are doing both?). Similarly, I fail to see any need for ORF (but admittedly, I haven't looked at it much) or using prefix lengths. Those who would like to distinguish prefix length in the prefix-limiter are probably confusing inbound policy with appropriate prefix-limits. So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and compact to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13153 for ; Mon, 26 Apr 2004 13:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9h7-0002zj-MV; Mon, 26 Apr 2004 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9YU-00006T-7W for idr@optimus.ietf.org; Mon, 26 Apr 2004 13:06: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 NAA03065 for ; Mon, 26 Apr 2004 13:06:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9YS-0006HF-9y for idr@ietf.org; Mon, 26 Apr 2004 13:06:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Xe-0006Dh-00 for idr@ietf.org; Mon, 26 Apr 2004 13:05:15 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BI9X5-00068u-00 for idr@ietf.org; Mon, 26 Apr 2004 13:04:39 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3QH495O019763; Mon, 26 Apr 2004 10:04:09 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3QH49xC019760; Mon, 26 Apr 2004 10:04:09 -0700 (PDT) Message-Id: <200404261704.i3QH49xC019760@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: [Idr] Soft-Notify as an IDR WG document In-Reply-To: <200404261501.i3QF1aJ01072@merlot.juniper.net> References: <200404261501.i3QF1aJ01072@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 26 Apr 2004 10:04:09 -0700 (PDT) Yakov Rekhter writes: > Folks, Please comment on the attached. The deadline for comments is > May 10. I dont think this document should be accepted as a work-group document. The unit of containment in bgp should be the session. We can possibly have multiple sessions between a pair of systems either via manual config or with the mecanism that Scudder is proposing. Attempting to reset a subset of the nlri is something that won't work in a considerable number of cases and that adds a very significant ammount of complexity to BGP. I would like to propose that the WG rejects this approach. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10485 for ; Mon, 26 Apr 2004 12:32: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 1BI8sn-0002QO-7A; Mon, 26 Apr 2004 12: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 1BFwq8-0004VR-0x for idr@optimus.ietf.org; Tue, 20 Apr 2004 11:07: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 LAA24120 for ; Tue, 20 Apr 2004 11:07:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwq5-0004ER-8x for idr@ietf.org; Tue, 20 Apr 2004 11:07:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwp2-0003vn-00 for idr@ietf.org; Tue, 20 Apr 2004 11:06:04 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 1BFwo0-0003aJ-00 for idr@ietf.org; Tue, 20 Apr 2004 11:05:00 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 169DC4FC51; Tue, 20 Apr 2004 11:04:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16517.15372.723230.469986@durmstrang.padfoot.com> From: Henry Kilmer To: "John G. Scudder" Cc: idr@ietf.org Subject: [Idr] Multisession as WG doc In-Reply-To: References: X-Mailer: VM 7.17 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 20 Apr 2004 11:04:44 -0400 John G. Scudder writes: >Hi Folks, > >I'd like to suggest that Multisession BGP >(draft-scudder-bgp-multisession-00.txt) be considered as an IDR >working group document. This document should definately be a WG document. -Hank _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06972 for ; Mon, 26 Apr 2004 11:27: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 1BI7q1-00059q-Ak; Mon, 26 Apr 2004 11:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7eK-0001ao-4G for idr@optimus.ietf.org; Mon, 26 Apr 2004 11:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25811 for ; Mon, 26 Apr 2004 11:03:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7eH-0004kW-IR for idr@ietf.org; Mon, 26 Apr 2004 11:03:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7dO-0004iA-00 for idr@ietf.org; Mon, 26 Apr 2004 11:03:02 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BI7cZ-0004bp-00 for idr@ietf.org; Mon, 26 Apr 2004 11:02:12 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3QF1fl61598 for ; Mon, 26 Apr 2004 08:01:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3QF1aJ01072 for ; Mon, 26 Apr 2004 08:01:36 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404261501.i3QF1aJ01072@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22294.1082991696.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] Soft-Notify as an IDR WG document 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, 26 Apr 2004 08:01:36 -0700 Folks, Please comment on the attached. The deadline for comments is May 10. Yakov. ------- Forwarded Message Date: Tue, 20 Apr 2004 12:47:27 -0700 From: Gargi Nalawade To: idr@ietf.org Subject: [Idr] Soft-Notify as IDR WG document Hi All, I would like to request that BGP Soft-Notify draft, draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG document. - -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA04439 for ; Mon, 26 Apr 2004 10:47: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 1BI7G9-0003l1-Me; Mon, 26 Apr 2004 10:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI76a-0000b6-R1 for idr@optimus.ietf.org; Mon, 26 Apr 2004 10:29: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 KAA23965 for ; Mon, 26 Apr 2004 10:29:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI76Y-0002qC-Hs for idr@ietf.org; Mon, 26 Apr 2004 10:29:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI75g-0002lY-00 for idr@ietf.org; Mon, 26 Apr 2004 10:28:12 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BI74P-0002dQ-00 for idr@ietf.org; Mon, 26 Apr 2004 10:26:53 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 40F422D4843 for ; Mon, 26 Apr 2004 10:26:23 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02499-04-21 for ; Mon, 26 Apr 2004 10:26:12 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E4D682D482F for ; Mon, 26 Apr 2004 10:26:11 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i3QEQBn12023 for idr@ietf.org; Mon, 26 Apr 2004 10:26:11 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Message-ID: <20040426102611.A11934@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 amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] [Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-idr-bgp4-mib-14.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, 26 Apr 2004 10:26:11 -0400 Gentles, This document incorporates all last-call comments from Sharon. ----- Forwarded message from 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 : 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-14.txt Pages : 35 Date : 2004-4-23 This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269. [...] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-14.txt ----- End forwarded message ----- -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA21040 for ; Fri, 23 Apr 2004 16:26: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 1BH6b2-0003z6-Mn; Fri, 23 Apr 2004 15:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6TU-0000xQ-98 for idr@optimus.ietf.org; Fri, 23 Apr 2004 15:36:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03470; Fri, 23 Apr 2004 15:36:33 -0400 (EDT) Message-Id: <200404231936.PAA03470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-mib-14.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, 23 Apr 2004 15:36:33 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : 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-14.txt Pages : 35 Date : 2004-4-23 This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269. 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. This memo is intended to document deployed implementations of this MIB in a historical context, provide clarifications of some items and also note errors where the MIB fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB with a new one representing the current state of the BGP protocol and its extensions. Distribution of this memo is unlimited. Please forward comments to idr@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-14.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-14.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: <2004-4-23150624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-23150624.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA20890 for ; Fri, 23 Apr 2004 01:35: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 1BGtBQ-0007nV-Jz; Fri, 23 Apr 2004 01:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGt6B-0005kz-Hc for idr@optimus.ietf.org; Fri, 23 Apr 2004 01:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00487 for ; Fri, 23 Apr 2004 01:19:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGt66-0007Z9-G7 for idr@ietf.org; Fri, 23 Apr 2004 01:19:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGt56-0007HD-00 for idr@ietf.org; Fri, 23 Apr 2004 01:18:33 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGt45-0006kk-00 for idr@ietf.org; Fri, 23 Apr 2004 01:17:29 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3N5Gmf22934; Fri, 23 Apr 2004 08:16:49 +0300 From: Pekka Savola To: Susan Hares cc: Yakov Rekhter , Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 23 Apr 2004 08:16:48 +0300 (EEST) On Thu, 15 Apr 2004, Susan Hares wrote: > Can you clarify something here: > 1) Your need - informing the remote peer of > warning limits, stop receive limits, and drop limits > and SNMP traps, logs etcs > > is the basis for the draft. We don't really *need* this, because we're monitoring the number of prefixes advertised by peers. If they go over the top, an alarm sounds in the NOC. There is no need to inform the peer of the prefix limits we use, as no prefixes should be dropped based on that, and if they are, the peer has been badly misbehaving and deserves what it got. Remember, if a peer advertises 100 prefixes, you don't set the prefix limits to 101 prefixes or even 110 prefixes, but probably something like 200 or 500 prefixes. Our threat model here is, "we want to stop peers from accidentally advertising the whole Internet or a lot more routes than is normal to us." I.e., a properly administered systems do not need this option. But I would not object to having a simple option if that's what others see useful. I would object to creating a complex option, because that seems to go too much beyond the cost/benefit curve for an option which is not needed at all in the first place. > 2) Providers we talk to had 2 cases: > > 1) creeping VPN prefix limits > 2) dump of whole routing table > > The need to treat the two differently. No, I think I disagree with this. Why would they have to be treated differently? It's the number of prefixes per peer that counts, not per AFI/SAFI etc. used, or the manner by which they're transmitted. You protect your gear at the edge of the network, from either your peers or your customers (if you import their routes into VPN), so distinguishing per VPN doesn't seem to be all that useful. > 3) Set until changed - that's the rub > > The providers wanted to negotiate the capabilties and > upgrade the capabilities without dropping the connect. > > Is that what you mean as well? If so, could you comment > on what is complex. Currently, adding prefix-limits does not drop a session, so it's required that sessions aren't dropped if the prefix-limits are changed either. That means that if prefix-limit negotiation is specified, it must not require a session reset, yes. > History: > We started this out with capabilities on open, and dynamic > capabilities. Due to some vendor's request to include other > mechanism (ORF, Soft Notify) to support the dynamic features - > we added the rest. > > Other service providers said, Love the function but could you > do it by prefix lengths. > > In an effort to get something working for all these folks, > we made these other features optional. > > What part don't you like? Cause everything you stated you wanted -- > is the basic part of the initial draft? Did you dis-like the additions > (ORF, Soft Notify) and or the optional sub-codes? > > Do you think we should go back to the initial draft simplistic model? It seems to me that if dynamic capabilities is a required-to-implement mechanism, soft-notify is useless or even problematic (what if you are doing both?). Similarly, I fail to see any need for ORF (but admittedly, I haven't looked at it much) or using prefix lengths. Those who would like to distinguish prefix length in the prefix-limiter are probably confusing inbound policy with appropriate prefix-limits. So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and compact to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA21574 for ; Thu, 22 Apr 2004 05:59:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGauC-0003Kv-AS; Thu, 22 Apr 2004 05:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGanC-0000KG-NO for idr@optimus.ietf.org; Thu, 22 Apr 2004 05:46: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 FAA14962 for ; Thu, 22 Apr 2004 05:46:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGan7-0004tL-83 for idr@ietf.org; Thu, 22 Apr 2004 05:46:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGamG-0004f3-00 for idr@ietf.org; Thu, 22 Apr 2004 05:45:53 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGalN-0004CO-00 for idr@ietf.org; Thu, 22 Apr 2004 05:44:57 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3M9iQW04279; Thu, 22 Apr 2004 12:44:26 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt In-Reply-To: <200404162121.i3GLLDJ87448@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 22 Apr 2004 12:44:26 +0300 (EEST) On Fri, 16 Apr 2004, Yakov Rekhter wrote: > During the Last Call it would be greatly appreciated if folks would > read the document and comment on it to the IDR mailing list. In > other words, we need "yes, looks good" or "should fix this and > that", not just silence. In general, I think this should be rather close to being ready for going forward. A few quick comments: - the text could use a lot more updates, but is readable as it is. - where are the implementation & interop reports? - several ID-nits or other process issues must be fixed, at least: o Status of this memo, Abstract, etc. must be unnumbered sections (typically Introduction is section number 1) o No references in the abstract. o One cannot have normative references to documents of lower maturity level. I suggest moving everything except [1] (or maybe also [7]) to a new Informational References section. o The document should probably say (in Abstract and Introduction) that this document Obsoletes both 2796 and 1966 (note 2796 only Updates 1966, which was probably a bug.)? o Standard IPR statement is needed at the end even if there is is no IPR. The date in the copyright statement is 4 years old as well.. o every empty line in this memo is duplicated (due to flawed DOS/WINDOWS -> Unix conversion?) - food for thought: should we kill two birds in one stone, and also declare RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh routing") historic? Is that useful anymore? - A few rewordings I spotted (I grew bored with the text soon after the abstract, as there would have been a lot of changes): Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. ==> s/Currently in the Internet BGP deployments are configured such that that/Typically/ (the same in the Introduction) information, as is common in many of todays internet networks. ==> s/todays internet/today's Internet/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA19212 for ; Thu, 22 Apr 2004 05:35: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 1BGaPF-0006zF-Ea; Thu, 22 Apr 2004 05:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaN7-0005SH-5j for idr@optimus.ietf.org; Thu, 22 Apr 2004 05:19: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 FAA13806 for ; Thu, 22 Apr 2004 05:19:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaN1-0006Lx-Vc for idr@ietf.org; Thu, 22 Apr 2004 05:19:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaM7-00068s-00 for idr@ietf.org; Thu, 22 Apr 2004 05:18:51 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BGaLi-0005vS-00 for idr@ietf.org; Thu, 22 Apr 2004 05:18:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3M9Hr903947; Thu, 22 Apr 2004 12:17:53 +0300 From: Pekka Savola To: Pedro Roque Marques cc: Yakov Rekhter , Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document In-Reply-To: <200404211833.i3LIXZiD005554@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 22 Apr 2004 12:17:53 +0300 (EEST) Hi, For what it's worth, it seems to me that this memo is a solution looking for the problem. Why do we need this in the first place? To "standardize" commonly used communities? To give the users more tools to mess up their routing, or to allow the users to make the ISP's policy more complex? I'm skeptical about the usefulness of this approach. A few nits: - if EX-COMM doesn't support IPv6 addresses, and that is important enough, the support MUST be added. - it might make sense to switch the order of Length and "ASN" fields for better alignment. Length could also include the ASN field. (Maybe this would be a more typical TLV encoding?) On Wed, 21 Apr 2004, Pedro Roque Marques wrote: > Yakov Rekhter writes: > > Folks, It would be greatly appreciated if folks would read the > > document and comment on it to the IDR mailing list. In other words, > > we need "yes, looks good" or "should fix this and that", not just > > silence. > > my recollection is that this draft has been discussed before and that > the majority of the WG requested that encoding and applications of > communities be kept separate. > > reclying the comments: it does appear that the propossed applications > are possible w/ existing protocol support. The author recognises that > some of those applications may or may not be a good idea given that > they seem to impose on an ISP a set of policies which the ISP may or > may not wish to provide... > > reading the document, it seems that the original comments are still > relevant. > > i also believe that embeding ipv4 and ipv6 addresses into communities is > not a feature... addresses don't make for very good identifiers given > that they may change. > > Pedro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA15974 for ; Tue, 20 Apr 2004 23:52: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 1BG8gX-0001rh-UG; Tue, 20 Apr 2004 23:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8UH-0004ub-2o for idr@optimus.ietf.org; Tue, 20 Apr 2004 23:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19846 for ; Tue, 20 Apr 2004 23:33:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8UE-0002dF-SF for idr@ietf.org; Tue, 20 Apr 2004 23:33:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8TG-0002YN-00 for idr@ietf.org; Tue, 20 Apr 2004 23:32:22 -0400 Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx with esmtp (Exim 4.12) id 1BG8SG-0002QG-00 for idr@ietf.org; Tue, 20 Apr 2004 23:31:20 -0400 Received: by mail.castlepoint.net (Postfix, from userid 500) id 6472513AC8; Tue, 20 Apr 2004 21:31:20 -0600 (MDT) From: Shane Amante To: idr@ietf.org Subject: Re: [Idr] Multisession as WG doc Message-ID: <20040421033120.GA1689@ns1.castlepoint.net> Mail-Followup-To: idr@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 20 Apr 2004 21:31:20 -0600 I support making this a WG document. -shane On Mon, Apr 19, 2004 at 03:42:25PM -0400, John G. Scudder wrote: > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12001 for ; Tue, 20 Apr 2004 16:22: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 1BG1PV-0000OT-KK; Tue, 20 Apr 2004 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Ft-0005GD-2U for idr@optimus.ietf.org; Tue, 20 Apr 2004 15:50:05 -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 PAA17884 for ; Tue, 20 Apr 2004 15:50:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1Fr-000503-F8 for idr@ietf.org; Tue, 20 Apr 2004 15:50:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1En-0004pQ-00 for idr@ietf.org; Tue, 20 Apr 2004 15:48:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BG1Dg-0004d2-00 for idr@ietf.org; Tue, 20 Apr 2004 15:47:48 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 Apr 2004 12:48:23 -0700 Received: from cisco.com ([128.107.177.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3KJlGqi021754 for ; Tue, 20 Apr 2004 12:47:16 -0700 (PDT) Message-ID: <40857E4F.3040304@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: [Idr] Soft-Notify as IDR WG document Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.82] X-PMX-Version: 4.5.0.92886 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 20 Apr 2004 12:47:27 -0700 Hi All, I would like to request that BGP Soft-Notify draft, draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG document. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA11229 for ; Tue, 20 Apr 2004 14:54: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 1BG09B-0008Ng-Ge; Tue, 20 Apr 2004 14:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG02U-0005cA-1P for idr@optimus.ietf.org; Tue, 20 Apr 2004 14:32: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 OAA10528 for ; Tue, 20 Apr 2004 14:32:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG02R-0006ML-D4 for idr@ietf.org; Tue, 20 Apr 2004 14:32:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG01U-0006IN-00 for idr@ietf.org; Tue, 20 Apr 2004 14:31:09 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BG00Y-0006CX-00 for idr@ietf.org; Tue, 20 Apr 2004 14:30:10 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWH00837F3DY0@firewall.mci.com> for idr@ietf.org; Tue, 20 Apr 2004 18:23:37 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWH00I01EYSMM@pmismtp02.mcilink.com>; Tue, 20 Apr 2004 18:23:37 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.163]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWH00I2TF12ME@pmismtp02.mcilink.com>; Tue, 20 Apr 2004 18:22:14 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-reply-to: <9473683187ADC049A855ED2DA739ABCA02BA3AFF@KCCLUST06EVS1.ugd.att.com> To: "'Ash, Gerald R (Jerry), ALABS'" , idr@ietf.org, "'Yakov Rekhter'" Message-id: <009a01c42704$67888850$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 20 Apr 2004 14:22:14 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA11229 This draft proposes some reasonable approach to solve some existing issues. In VPN world the number of prefixes can slowly creep up and an elaborate mechanism for warning, stop and reset could be helpful but in public SP world in most of the cases the SP maintains a static prefix-list for each customer. Usually the customer needs to contact the SP if they need to modify that prefix-list. Typically though, the SP accepts any prefixes which are more specific to the ones maintained in the prefix-list filter. The problem arises when the customer accidentally de-aggregates their prefixes. And when that happens depending on the block that got de-aggregated, the number prefix send by customer could experience a sudden sizeable jump. In today's world, there is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session would go down permanently if the max-prefix-limit is exceeded. It would take an urgent operator intervention to bring it up again, of course the operator would need to make sure the cause has been taken care off before bringing the session up. So if we want to use the draft approach to take care of this particular scenario, a filtering mechanism depending on the specificity of a prefix could become important. For, e.g., if a session hits the stop level, the sender could resend all its prefixes after filtering out any prefix more specific to /24 etc. Of course this specificity should be configurable. However, if for example, /24 is chosen, it would ensure all the customer prefixes are still globally routable, but some of their load-balancing mechanism can get affected. So the price the customer pays for the mishap gets less harsh. On the other hand, the approach mentioned in the draft could be useful on the BGP sessions used for peering with equivalent SP peers. -Parantap -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Ash, Gerald R (Jerry), ALABS Sent: Tuesday, April 20, 2004 8:52 AM To: idr@ietf.org; Yakov Rekhter Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. This draft addresses an important issue, and proposes a reasonable approach to address the issue. I support this becoming a WG document. Jerry _______________________________________________ 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 (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07674 for ; Tue, 20 Apr 2004 10:59:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwQo-0003vB-Nm; Tue, 20 Apr 2004 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwOz-0003Ho-Tb for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:39: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 KAA22237 for ; Tue, 20 Apr 2004 10:39:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwOx-00048q-IH for idr@ietf.org; Tue, 20 Apr 2004 10:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwO2-0003ra-00 for idr@ietf.org; Tue, 20 Apr 2004 10:38:11 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BFwN5-0003Km-00 for idr@ietf.org; Tue, 20 Apr 2004 10:37:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3KEafBm078544 for ; Tue, 20 Apr 2004 07:36:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KEafJ43860 for ; Tue, 20 Apr 2004 07:36:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201436.i3KEafJ43860@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48430.1082471801.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-scudder-bgp-multisession-00.txt as an IDR WG document 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, 20 Apr 2004 07:36:41 -0700 Folks, Please comment on the attached. The deadline for comments is May 3. Yakov. ------- Forwarded Message Date: Mon, 19 Apr 2004 15:42:25 -0400 From: "John G. Scudder" To: idr@ietf.org Subject: [Idr] Multisession as WG doc Hi Folks, I'd like to suggest that Multisession BGP (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working group document. Thanks, - --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07614 for ; Tue, 20 Apr 2004 10:58:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwQ1-0003t7-RI; Tue, 20 Apr 2004 10:40:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwN1-0002EF-5Q for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:37:07 -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 KAA22095 for ; Tue, 20 Apr 2004 10:37:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwMy-0003ZU-Nx for idr@ietf.org; Tue, 20 Apr 2004 10:37:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwLy-0003IU-00 for idr@ietf.org; Tue, 20 Apr 2004 10:36:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BFwL1-0002ns-00 for idr@ietf.org; Tue, 20 Apr 2004 10:35:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2004 07:46:55 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (dhcp-kta1-161-44-192-234.cisco.com [161.44.192.234]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3KEYUAH012869 for ; Tue, 20 Apr 2004 10:34:31 -0400 (EDT) From: "zafar ali" To: "'idr'" Subject: RE: [Idr] Multisession as WG doc Organization: Cisco Systems Message-ID: <000001c426e4$9e959a60$eac02ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: <68FBC308-9282-11D8-8B6C-000393D54EA6@tcb.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 20 Apr 2004 10:34:38 -0400 > > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. I support this notion. Thanks Regards... Zafar _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06202 for ; Tue, 20 Apr 2004 10:29:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFw2f-0003NL-Kb; Tue, 20 Apr 2004 10:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvtv-0003gi-1s for idr@optimus.ietf.org; Tue, 20 Apr 2004 10:07:03 -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 KAA19472 for ; Tue, 20 Apr 2004 10:06:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvts-0002tx-NE for idr@ietf.org; Tue, 20 Apr 2004 10:07:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvst-0002c0-00 for idr@ietf.org; Tue, 20 Apr 2004 10:05:59 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BFvrt-00024P-00 for idr@ietf.org; Tue, 20 Apr 2004 10:04:57 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3KE4Q5G022841 for ; Tue, 20 Apr 2004 07:04:26 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3KE4Qa6022840 for idr@ietf.org; Tue, 20 Apr 2004 07:04:26 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f From: David Meyer To: idr Subject: Re: [Idr] Multisession as WG doc Message-ID: <20040420140426.GB22815@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 20 Apr 2004 07:04:26 -0700 On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote: >Hi Folks, > >I'd like to suggest that Multisession BGP >(draft-scudder-bgp-multisession-00.txt) be considered as an IDR >working group document. I support this document becoming a WG document. Dave _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05432 for ; Tue, 20 Apr 2004 10:14: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 1BFvrz-0002mR-0q; Tue, 20 Apr 2004 10:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvkT-0005Ec-66 for idr@optimus.ietf.org; Tue, 20 Apr 2004 09:57:17 -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 JAA18226 for ; Tue, 20 Apr 2004 09:57:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvkR-0007UG-4L for idr@ietf.org; Tue, 20 Apr 2004 09:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvjV-0007C3-00 for idr@ietf.org; Tue, 20 Apr 2004 09:56:18 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BFvia-0006d7-00 for idr@ietf.org; Tue, 20 Apr 2004 09:55:20 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3KDsfBm078422; Tue, 20 Apr 2004 06:54:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KDsbJ39849; Tue, 20 Apr 2004 06:54:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201354.i3KDsbJ39849@merlot.juniper.net> To: Stephen Kent cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 16 Apr 2004 18:50:54 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42557.1082469277.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 20 Apr 2004 06:54:37 -0700 Steve, > >> >Steve, would you mind making a suggestion on how the text could > >>be improved? > >> >E.g., would a separate section in the main body of the document specifyi ng > >> >the requirement for TCP-MD5 support be useful? > >> > >> A reasonable approach would be to have a section of the document that > >> describes the use of this TCP option. It should explain why/when one > >> would use the option in the context of BGP links and what protection > >> it offers. > > > >Would you please produce the appropriate text for this section. > > > >Thanks in advance. > > > >Yakov. > > I'll try to provide some text when I return from vacation, in early May. Thanks !!! Looking forward to get the text. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05141 for ; Tue, 20 Apr 2004 10:11:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvqz-0002F2-JB; Tue, 20 Apr 2004 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFviO-0002F5-5G for idr@optimus.ietf.org; Tue, 20 Apr 2004 09:55: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 JAA18099 for ; Tue, 20 Apr 2004 09:55:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFviM-0006rz-5L for idr@ietf.org; Tue, 20 Apr 2004 09:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvhW-0006cW-00 for idr@ietf.org; Tue, 20 Apr 2004 09:54:14 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BFvgz-0006MJ-00 for idr@ietf.org; Tue, 20 Apr 2004 09:53:41 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3KDr7l13986; Tue, 20 Apr 2004 06:53:07 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KDr1J39724; Tue, 20 Apr 2004 06:53:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404201353.i3KDr1J39724@merlot.juniper.net> To: Alex Zinin cc: Pekka Savola , ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: Your message of "Mon, 19 Apr 2004 14:53:55 PDT." <616478494.20040419145355@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42442.1082469181.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 20 Apr 2004 06:53:01 -0700 Alex, > Pekka, > > [cc'ing IDR] > > Thanks for a careful follow-up. Inline below, pls. > > Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote: > > On Fri, 19 Mar 2004, Alex Zinin wrote: > >> Below is the IETF LC announcement that should have made it to several > >> lists and hasn't yet > >> > >> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html > > > FWIW, I looked at this when it was at WG, and I noticed two > > operationally particularly bad things that have both bitten us a lot > > in our network (and many other networks): > > > 1) the definition of route resolvability in the presence of > > discard/null0/reject/etc. routes is very unfortunate. That is, if > > you happen to have to have a default route or an aggregate in your > > iBGP, when a router goes down and the loopback matches that route, the > > prefixes that were advertised by the router that went down aren't > > considered unresolvable, but you have to wait for BGP timeout. > > > There seemed to be no consensus to change this at this point, as a > > DDoS tracing technique depends on that discard/null0 resolvability > > "feature". > > > > > > This was discussed at idr thread: > > > > issue: bgp4-23: route resolvability and discard/null0 routes > > If memory serves, the discussion resulted in a suggestion to put this > consideration in one of the accompanying documents. Sue, Yakov, please > check. The suggestion on the mailing list was *not* to put this consideration into one of the accompanying documents, but to produce a *separate* Internet Draft that cover this (see e-mails on 3/12/2004). > > 2) The definition of active route is bad. This fails in the > > situation where you need to export loopbacks/point-to-points to > > eBGP, but you have them in youro IGP. The specification does not > > consider them active (not used for forwarding), and they aren't > > exported. > > > > When the next-hop of the IGP route is the same as BGP next-hop, > > obviously this is no problem. Gargi Nalawade promised to submit > > text, but hasn't, and I think Yakov said something about being > > willing to incorporate that, but obviously hasn't. > > > > This was discussed at idr thread: > > > issue 11.2: active route, again > > > Otherwise, I think this was operationally good. > > Sue, Yakov, please check if the ball was dropped re this one. First of all, the consensus of the WG (as documented in draft-ietf-idr-bgp-issues) is to have the following text: In the context of this document we assume that a BGP speaker advertises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. While this text does not cover the case described by Pekka, it does not preclude it either - handling the case described by Pekka is just outside the scope of the spec. With this in mind I suggest that the case described by Pekka should be covered in a separate Internet Draft. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA01759 for ; Tue, 20 Apr 2004 09:04:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuoO-0006aV-Og; Tue, 20 Apr 2004 08:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFulc-00052u-BM for idr@optimus.ietf.org; Tue, 20 Apr 2004 08:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14545 for ; Tue, 20 Apr 2004 08:54:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFula-000579-Ok for idr@ietf.org; Tue, 20 Apr 2004 08:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFukf-0004oQ-00 for idr@ietf.org; Tue, 20 Apr 2004 08:53:25 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BFujv-0004VN-00 for idr@ietf.org; Tue, 20 Apr 2004 08:52:39 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3KChM6O006336 for ; Tue, 20 Apr 2004 08:52:09 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 4082A75C0005D601; Tue, 20 Apr 2004 08:51:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3AFF@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Support for the prefix limit draft Thread-Index: AcQjAWew+sfOI/IRTseLeKmCHHD90AD0kojgAAA7pZA= From: "Ash, Gerald R (Jerry), ALABS" To: , "Yakov Rekhter" Cc: "Ash, Gerald R (Jerry), ALABS" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 20 Apr 2004 07:52:08 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA01759 > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. This draft addresses an important issue, and proposes a reasonable approach to address the issue. I support this becoming a WG document. Jerry _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA06060 for ; Tue, 20 Apr 2004 00:35: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 1BFmtY-00038s-46; Tue, 20 Apr 2004 00:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmoO-0001j3-PT for idr@optimus.ietf.org; Tue, 20 Apr 2004 00:24:44 -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 AAA05687 for ; Tue, 20 Apr 2004 00:24:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFmoM-0002BP-5N for idr@ietf.org; Tue, 20 Apr 2004 00:24:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmnO-0001ws-00 for idr@ietf.org; Tue, 20 Apr 2004 00:23:42 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1BFmmp-0001ie-00 for idr@ietf.org; Tue, 20 Apr 2004 00:23:07 -0400 Received: from [205.168.100.17] (unknown [205.168.100.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id D6E5694621 for ; Mon, 19 Apr 2004 22:23:01 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <68FBC308-9282-11D8-8B6C-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Multisession as WG doc To: idr X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 19 Apr 2004 22:23:01 -0600 On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote: > Hi Folks, > > I'd like to suggest that Multisession BGP > (draft-scudder-bgp-multisession-00.txt) be considered as an IDR > working group document. I support this - I'm in favor of making it a WG document. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA02919 for ; Mon, 19 Apr 2004 23:35: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 1BFlyS-0006Rv-2O; Mon, 19 Apr 2004 23:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFlt6-0005GU-TY for idr@optimus.ietf.org; Mon, 19 Apr 2004 23:25: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 XAA02306 for ; Mon, 19 Apr 2004 23:25:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFlt4-0002OY-Tz for idr@ietf.org; Mon, 19 Apr 2004 23:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFls0-0001uG-00 for idr@ietf.org; Mon, 19 Apr 2004 23:24:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BFlqy-0001Z5-00 for idr@ietf.org; Mon, 19 Apr 2004 23:23:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2004 20:23:48 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3K3MnhE014235 for ; Mon, 19 Apr 2004 20:22:49 -0700 (PDT) Received: from [10.112.0.164] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA22026 for ; Mon, 19 Apr 2004 23:22:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no version=2.60 Subject: [Idr] Multisession as WG doc 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, 19 Apr 2004 15:42:25 -0400 Hi Folks, I'd like to suggest that Multisession BGP (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working group document. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16189 for ; Mon, 19 Apr 2004 18:13:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgq4-0004Jq-GX; Mon, 19 Apr 2004 18:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgk5-0001u6-2m for idr@optimus.ietf.org; Mon, 19 Apr 2004 17:55: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 RAA13373 for ; Mon, 19 Apr 2004 17:55:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgk2-0004jq-ET for idr@ietf.org; Mon, 19 Apr 2004 17:55:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFgj8-0004Sd-00 for idr@ietf.org; Mon, 19 Apr 2004 17:54:55 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFgiC-0004BA-00 for idr@ietf.org; Mon, 19 Apr 2004 17:53:56 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFgiB-000Myc-R7; Mon, 19 Apr 2004 21:53:55 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <616478494.20040419145355@psg.com> To: Pekka Savola CC: ops-dir@ops.ietf.org, idr@ietf.org Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard In-Reply-To: References: <139156231539.20040319113030@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 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, 19 Apr 2004 14:53:55 -0700 Pekka, [cc'ing IDR] Thanks for a careful follow-up. Inline below, pls. Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote: > On Fri, 19 Mar 2004, Alex Zinin wrote: >> Below is the IETF LC announcement that should have made it to several >> lists and hasn't yet >> >> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html > FWIW, I looked at this when it was at WG, and I noticed two > operationally particularly bad things that have both bitten us a lot > in our network (and many other networks): > 1) the definition of route resolvability in the presence of > discard/null0/reject/etc. routes is very unfortunate. That is, if > you happen to have to have a default route or an aggregate in your > iBGP, when a router goes down and the loopback matches that route, the > prefixes that were advertised by the router that went down aren't > considered unresolvable, but you have to wait for BGP timeout. > There seemed to be no consensus to change this at this point, as a > DDoS tracing technique depends on that discard/null0 resolvability > "feature". > This was discussed at idr thread: > issue: bgp4-23: route resolvability and discard/null0 routes If memory serves, the discussion resulted in a suggestion to put this consideration in one of the accompanying documents. Sue, Yakov, please check. > 2) The definition of active route is bad. This fails in the > situation where you need to export loopbacks/point-to-points to > eBGP, but you have them in youro IGP. The specification does not > consider them active (not used for forwarding), and they aren't > exported. > When the next-hop of the IGP route is the same as BGP next-hop, > obviously this is no problem. Gargi Nalawade promised to submit > text, but hasn't, and I think Yakov said something about being > willing to incorporate that, but obviously hasn't. > This was discussed at idr thread: > issue 11.2: active route, again > Otherwise, I think this was operationally good. Sue, Yakov, please check if the ball was dropped re this one. Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA11933 for ; Mon, 19 Apr 2004 16:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfae-00023l-CH; Mon, 19 Apr 2004 16:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfV1-0000LV-Aj for idr@optimus.ietf.org; Mon, 19 Apr 2004 16:36:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08336 for ; Mon, 19 Apr 2004 16:36:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfUz-0000YZ-CT for idr@ietf.org; Mon, 19 Apr 2004 16:36:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfU2-0000Kb-00 for idr@ietf.org; Mon, 19 Apr 2004 16:35:15 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BFfT4-0007fh-00 for idr@ietf.org; Mon, 19 Apr 2004 16:34:14 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i3JKXirS015123; Mon, 19 Apr 2004 13:33:44 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i3JKXive015122; Mon, 19 Apr 2004 13:33:44 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f From: David Meyer To: Alex Zinin Cc: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Message-ID: <20040419203344.GA15050@1-4-5.net> References: <107409968.20040419130650@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <107409968.20040419130650@psg.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 19 Apr 2004 13:33:44 -0700 All, Thanks for the comments. We're working on the update as we speak. BTW, wrt this: >> >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> > >> > 232 or 2^32? >> >> Neither makes much sense. Usually one would simply say O(M). >> >> >> (where M is a slow-moving function describing the AS >> >> interconnectivity of the network), >> > >> > slow-moving or slow-growing? >> >> I believe "slow-moving" is correct -- especially as compared to the >> speed of the arm-waving inherent in this sentence. ;^) what I was trying to get at is that the size of the RIB is going to be bounded by something like 2^32 *, where the represents the AS-meshiness, which (in practice) doesn't change at a very large rate. So O(M) is incorrect. The basic idea was to (attempt to) contrast the size of the RIB with its dynamic properties. So do people disagree that the size of the RIB is bounded in this way? Thanks, Dave >> I've received some more comments on this document included below. >> Please take them into consideration. >> >> Thanks. >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> >> # NLRI Mean AS Distance # AS's Bandwidth (MR) >> ^ ^ ^ ^ >> N M A BW >> >> ---------- ---------------- ------ ---------------- >> >> 40,000 15 400 184,000 bytes >> >> 100,000 10 10,000 800,000 bytes >> >> 120,000 10 15,000 1,080,000 bytes >> >> 140,000 15 20,000 1,760,000 bytes >> >> >> >> [note that most of this bandwidth is consumed by the NLRI exchange] >> > >> > Is the caption for column 3 correct? It says "# AS's", which reads as >> > "number of AS's" while it seems it should be the number of unique paths. >> >> The text is clear; but your caption would be better. >> >> At least here the arithmetic is right. >> >> BTW, the caption for column 4 is also wrong. "MR" hasn't been >> introduced yet. >> >> >> During periods of Internet instability, changes to the reachability >> >> information are passed between routers in UPDATE messages. The >> > >> > While theoretically the text is correct and we could talk about periods >> > of stability and instability of the Internet, I wonder if this text is >> > still applicable from the practical perspective. I.e., the continuous >> > churn that the Internet BGP speakers experience ensures that they >> > practically always have something to process. >> >> Agreed: this is as "stable" as we're going to get; we shouldn't call >> it "instability". >> >> > Probably instead of talking about periods of "Internet stability" and >> > "Internet instability" we could talk about something like "periods of >> > stable state among BGP speakers when they do no have new updates to >> > communicate to each other". >> >> That's accurate; but I wonder whether it's worth talking about. >> >> > Not sure I follow here. What is meant by the "steady state" here? If it >> > means convergence on a stable topology after the initial exchange of >> > updates, then why talk about "stability of the Internet"? >> >> I took this to mean that whenever a BGP session starts, there's a >> potentially long initial exchange of routes, and we mean to exclude >> that startup transient. >> >> But, of course, we're back to the "stable Internet" paradigm. :^( >> >> > In other words, if the Internet is unstable then can we say that the >> > BGP speakers are in steady state? >> >> We can, but it's kind of confusing. I believe the intent was to >> have a "slightly unstable" Internet causing CPU load which doesn't >> become visible until we get past the startup transient. >> >> > In the lack of topology changes, it seems that the consumption should >> > instead depend on the number of peers (affects KEEPALIVE processing) >> > and the number of persistently oscillating routes potentially present >> > in the network... >> >> I'd rather talk in those terms; but it's a rather major rewrite of >> this section. >> >> >> This assumes >> >> that as the Internet grows, the overall stability of the inter-AS >> >> connectivity of the Internet can be controlled. >> > >> > please specify how it is assumed to be "controlled", e.g. through operational >> > practices. >> >> I believe historically this meant route-flap damping. >> >> >> In particular, while >> >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> > >> > 232 or 2^32? >> >> Neither makes much sense. Usually one would simply say O(M). >> >> >> (where M is a slow-moving function describing the AS >> >> interconnectivity of the network), >> > >> > slow-moving or slow-growing? >> >> I believe "slow-moving" is correct -- especially as compared to the >> speed of the arm-waving inherent in this sentence. ;^) >> >> >> no such bound can be formulated >> >> for the dynamic properties (i.e., stability) of BGP. >> >> There's the "stability" word again. :^( >> >> >> Although, the >> >> dynamic properties of the network cannot be quantitatively bounded, >> >> they can be controlled within BGP. Beyond certain changes in the >> >> network, BGP can start to suppress such changes using BGP Route Flap >> >> Damping [RFC2439], pacing of its route updates, or BGP would be >> >> unable to keep up with the changes and force suppression of multiple >> >> changes over very short periods by causing the BGP peer socket to >> >> block on the sender. >> >> The arms are waving again. We list methods of suppressing _some_ >> multiple changes and claim this avoids suppression of multiple changes. >> (This sentence would be quite correct if we said "force suppression of >> _all_ changes...") >> >> >> 6.1.2. Memory requirements >> >> >> >> To quantify the worst case memory requirements for BGP, we denote the >> >> total number of networks in the Internet by N, the mean AS distance >> >> of the Internet by M (distance at the level of an autonomous system, >> >> expressed in terms of the number of autonomous systems), the total >> >> number of unique AS paths as A. Then the worst case memory >> >> requirements (MR) can be expressed as >> >> >> >> MR = O(N + (M * A)) >> >> >> >> Since a mean AS distance M is a slow moving function of the >> >> interconnectivity ("meshiness") of the Internet, for all practical >> >> purposes the worst case router memory requirements are on the order >> >> of the total number of networks in the Internet times the number of >> >> peers the local system is peering with. We expect that the total >> >> number of networks in the Internet will grow much faster than the >> >> average number of peers per router. As a result, BGP's memory >> >> scaling properties are linearly related to the total number of >> >> networks in the Internet. >> >> >> >> The following table illustrates typical memory requirements of a >> >> router running BGP. We denote average number of routes advertised by >> >> each peer as N, the total number of unique AS paths as A, the mean AS >> >> distance of the Internet as M (distance at the level of an autonomous >> >> system, expressed in terms of the number of autonomous systems), >> >> number of bytes required to store a route as R, and number of bytes >> >> required to store one AS in an AS path as P. It is assumed that each >> >> network is encoded as four bytes, each AS is encoded as two bytes, >> >> and each networks is reachable via some fraction of all of the peers >> >> (# BGP peers/per net). For purposes of the estimates here, we will >> >> calculate MR = ((N * R) + (M * A) * P) >> >> One is forced to guess that R = 4. >> >> I think the intent was that P is two times the BGP-peers column. >> >> >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) >> ^ ^ ^ ^ ^ >> N M A P (???) MR >> >> ---------- ---------------- ------ ------------------- -------------- >> >> 100,000 20 3,000 20 1,040,000 >> >> 100,000 20 15,000 20 1,040,000 >> >> 120,000 10 15,000 100 75,000,000 >> >> 140,000 15 20,000 100 116,000,000 >> >> Well, to tell truth, I've forgotten how I reproduced two of those MR >> numbers. But it's certainly obvious they can't all be right; and today I >> can't reproduce a single one of them. >> >> >> In analyzing BGP's memory requirements, we focus on the size of the >> >> forwarding table (and ignoring implementation details). In >> >> particular, we derive upper bounds for the size of the forwarding >> >> table. >> > >> > The above doesn't look like calculations for a forwarding table--the >> > FIB doesn't normally contact AS-PATH info or all possible paths to a >> > destination. >> >> Agreed. I didn't think that was a FIB calculation -- though I never >> was sure what it was... >> >> >> >> _______________________________________________ >> 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 (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA10345 for ; Mon, 19 Apr 2004 16:24: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 1BFf8j-0003Xp-Pu; Mon, 19 Apr 2004 16:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf3y-0002Rt-DT for idr@optimus.ietf.org; Mon, 19 Apr 2004 16:08:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06535 for ; Mon, 19 Apr 2004 16:08:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFf3w-0001HS-IE for idr@ietf.org; Mon, 19 Apr 2004 16:08:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFf34-00014Z-00 for idr@ietf.org; Mon, 19 Apr 2004 16:07:23 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFf2Z-0000qr-00 for idr@ietf.org; Mon, 19 Apr 2004 16:06:51 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFf2Z-000Jyr-Nj for idr@ietf.org; Mon, 19 Apr 2004 20:06:51 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <107409968.20040419130650@psg.com> To: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 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, 19 Apr 2004 13:06:50 -0700 Folks- I've received some more comments on this document included below. Please take them into consideration. Thanks. -- Alex http://www.psg.com/~zinin/ >> # NLRI Mean AS Distance # AS's Bandwidth (MR) ^ ^ ^ ^ N M A BW >> ---------- ---------------- ------ ---------------- >> 40,000 15 400 184,000 bytes >> 100,000 10 10,000 800,000 bytes >> 120,000 10 15,000 1,080,000 bytes >> 140,000 15 20,000 1,760,000 bytes >> >> [note that most of this bandwidth is consumed by the NLRI exchange] > > Is the caption for column 3 correct? It says "# AS's", which reads as > "number of AS's" while it seems it should be the number of unique paths. The text is clear; but your caption would be better. At least here the arithmetic is right. BTW, the caption for column 4 is also wrong. "MR" hasn't been introduced yet. >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The > > While theoretically the text is correct and we could talk about periods > of stability and instability of the Internet, I wonder if this text is > still applicable from the practical perspective. I.e., the continuous > churn that the Internet BGP speakers experience ensures that they > practically always have something to process. Agreed: this is as "stable" as we're going to get; we shouldn't call it "instability". > Probably instead of talking about periods of "Internet stability" and > "Internet instability" we could talk about something like "periods of > stable state among BGP speakers when they do no have new updates to > communicate to each other". That's accurate; but I wonder whether it's worth talking about. > Not sure I follow here. What is meant by the "steady state" here? If it > means convergence on a stable topology after the initial exchange of > updates, then why talk about "stability of the Internet"? I took this to mean that whenever a BGP session starts, there's a potentially long initial exchange of routes, and we mean to exclude that startup transient. But, of course, we're back to the "stable Internet" paradigm. :^( > In other words, if the Internet is unstable then can we say that the > BGP speakers are in steady state? We can, but it's kind of confusing. I believe the intent was to have a "slightly unstable" Internet causing CPU load which doesn't become visible until we get past the startup transient. > In the lack of topology changes, it seems that the consumption should > instead depend on the number of peers (affects KEEPALIVE processing) > and the number of persistently oscillating routes potentially present > in the network... I'd rather talk in those terms; but it's a rather major rewrite of this section. >> This assumes >> that as the Internet grows, the overall stability of the inter-AS >> connectivity of the Internet can be controlled. > > please specify how it is assumed to be "controlled", e.g. through operational > practices. I believe historically this meant route-flap damping. >> In particular, while >> the size of the IPv4 Internet routing table is bounded by O(232 * M), > > 232 or 2^32? Neither makes much sense. Usually one would simply say O(M). >> (where M is a slow-moving function describing the AS >> interconnectivity of the network), > > slow-moving or slow-growing? I believe "slow-moving" is correct -- especially as compared to the speed of the arm-waving inherent in this sentence. ;^) >> no such bound can be formulated >> for the dynamic properties (i.e., stability) of BGP. There's the "stability" word again. :^( >> Although, the >> dynamic properties of the network cannot be quantitatively bounded, >> they can be controlled within BGP. Beyond certain changes in the >> network, BGP can start to suppress such changes using BGP Route Flap >> Damping [RFC2439], pacing of its route updates, or BGP would be >> unable to keep up with the changes and force suppression of multiple >> changes over very short periods by causing the BGP peer socket to >> block on the sender. The arms are waving again. We list methods of suppressing _some_ multiple changes and claim this avoids suppression of multiple changes. (This sentence would be quite correct if we said "force suppression of _all_ changes...") >> 6.1.2. Memory requirements >> >> To quantify the worst case memory requirements for BGP, we denote the >> total number of networks in the Internet by N, the mean AS distance >> of the Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths as A. Then the worst case memory >> requirements (MR) can be expressed as >> >> MR = O(N + (M * A)) >> >> Since a mean AS distance M is a slow moving function of the >> interconnectivity ("meshiness") of the Internet, for all practical >> purposes the worst case router memory requirements are on the order >> of the total number of networks in the Internet times the number of >> peers the local system is peering with. We expect that the total >> number of networks in the Internet will grow much faster than the >> average number of peers per router. As a result, BGP's memory >> scaling properties are linearly related to the total number of >> networks in the Internet. >> >> The following table illustrates typical memory requirements of a >> router running BGP. We denote average number of routes advertised by >> each peer as N, the total number of unique AS paths as A, the mean AS >> distance of the Internet as M (distance at the level of an autonomous >> system, expressed in terms of the number of autonomous systems), >> number of bytes required to store a route as R, and number of bytes >> required to store one AS in an AS path as P. It is assumed that each >> network is encoded as four bytes, each AS is encoded as two bytes, >> and each networks is reachable via some fraction of all of the peers >> (# BGP peers/per net). For purposes of the estimates here, we will >> calculate MR = ((N * R) + (M * A) * P) One is forced to guess that R = 4. I think the intent was that P is two times the BGP-peers column. >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) ^ ^ ^ ^ ^ N M A P (???) MR >> ---------- ---------------- ------ ------------------- -------------- >> 100,000 20 3,000 20 1,040,000 >> 100,000 20 15,000 20 1,040,000 >> 120,000 10 15,000 100 75,000,000 >> 140,000 15 20,000 100 116,000,000 Well, to tell truth, I've forgotten how I reproduced two of those MR numbers. But it's certainly obvious they can't all be right; and today I can't reproduce a single one of them. >> In analyzing BGP's memory requirements, we focus on the size of the >> forwarding table (and ignoring implementation details). In >> particular, we derive upper bounds for the size of the forwarding >> table. > > The above doesn't look like calculations for a forwarding table--the > FIB doesn't normally contact AS-PATH info or all possible paths to a > destination. Agreed. I didn't think that was a FIB calculation -- though I never was sure what it was... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02923 for ; Mon, 19 Apr 2004 14:02: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 1BFd0w-00020T-2W; Mon, 19 Apr 2004 13:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcE7-0005Rm-33 for idr@optimus.ietf.org; Fri, 16 Apr 2004 18:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17600 for ; Fri, 16 Apr 2004 18:54:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEcE3-0000eL-ST for idr@ietf.org; Fri, 16 Apr 2004 18:54:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcD3-0000Zp-00 for idr@ietf.org; Fri, 16 Apr 2004 18:53:21 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BEcC4-0000VT-00 for idr@ietf.org; Fri, 16 Apr 2004 18:52:20 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3GMpn7X007020; Fri, 16 Apr 2004 18:51:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404142038.i3EKcHJ88016@merlot.juniper.net> References: <200404142038.i3EKcHJ88016@merlot.juniper.net> To: Yakov Rekhter From: Stephen Kent Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt Cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 16 Apr 2004 18:50:54 -0400 At 1:38 PM -0700 4/14/04, Yakov Rekhter wrote: >Steve, > >> > >> > >> > >> >Steve, would you mind making a suggestion on how the text could >>be improved? >> >E.g., would a separate section in the main body of the document specifying >> >the requirement for TCP-MD5 support be useful? >> >> A reasonable approach would be to have a section of the document that >> describes the use of this TCP option. It should explain why/when one >> would use the option in the context of BGP links and what protection >> it offers. > >Would you please produce the appropriate text for this section. > >Thanks in advance. > >Yakov. I'll try to provide some text when I return from vacation, in early May. Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02881 for ; Mon, 19 Apr 2004 14:01: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 1BFd0v-00020L-J5; Mon, 19 Apr 2004 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESUw-0007BM-RY for idr@optimus.ietf.org; Fri, 16 Apr 2004 08:31: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 IAA04053 for ; Fri, 16 Apr 2004 08:31:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BESUv-0006kz-KO for idr@ietf.org; Fri, 16 Apr 2004 08:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESTx-0006dc-00 for idr@ietf.org; Fri, 16 Apr 2004 08:30:10 -0400 Received: from aismtp1g.bellsouth.com ([139.76.165.196]) by ietf-mx with esmtp (Exim 4.12) id 1BEST1-0006Q7-00 for idr@ietf.org; Fri, 16 Apr 2004 08:29:11 -0400 Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP for idr@ietf.org; Fri, 16 Apr 2004 08:28:41 -0400 content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Priority: normal Importance: normal Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423AE.569985C0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: Thread-Topic: Peer Prefix Limits Exchange in BGP Thread-Index: AcQjrlagAp0P6YTmTHu8aoJkedLcdA== From: "Miri, Mohammad" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Idr] Peer Prefix Limits Exchange in BGP 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, 16 Apr 2004 07:28:35 -0500 This is a multi-part message in MIME format. ------_=_NextPart_001_01C423AE.569985C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Title : Peer Prefix Limits Exchange in BGP=20 Author(s) : V. Radoaca, et al.=20 Filename : draft-chavali-bgp-prefixlimit-01.txt=20 Pages : 14=20 Date : 2004-4-12=20 I would like to request this this draft becoming a working group draft. = Discussion during IETF=20 58, indicated there was interest from service providers to having this = become a working group=20 draft.=20 ***** "The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination = or other use of, or taking of any action in reliance upon, this = information by persons or entities other than the intended recipient is = prohibited. If you received this in error, please contact the sender = and delete the material from all computers." 113 ------_=_NextPart_001_01C423AE.569985C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peer Prefix Limits Exchange in BGP

        = Title           : Peer = Prefix Limits Exchange in BGP

        = Author(s)       : V. Radoaca, et al. =

        = Filename        : = draft-chavali-bgp-prefixlimit-01.txt

        = Pages           : 14 =

        = Date            : = 2004-4-12

I would like to request this this draft becoming a = working group draft.  Discussion during IETF

58, indicated there was interest from service = providers to having this become a working group

draft.

*****

"The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon, this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers." 113

 ------_=_NextPart_001_01C423AE.569985C0-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21113 for ; Fri, 16 Apr 2004 17:41:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxL-0008T9-4E; Fri, 16 Apr 2004 17:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEapt-0006CJ-53 for idr@optimus.ietf.org; Fri, 16 Apr 2004 17:25:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11153 for ; Fri, 16 Apr 2004 17:25:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEapq-0002xN-OV for idr@ietf.org; Fri, 16 Apr 2004 17:25:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaos-0002vu-00 for idr@ietf.org; Fri, 16 Apr 2004 17:24:19 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEao1-0002u2-00 for idr@ietf.org; Fri, 16 Apr 2004 17:23:25 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3GLMtl98124 for ; Fri, 16 Apr 2004 14:22:55 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3GLMoJ87986 for ; Fri, 16 Apr 2004 14:22:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404162122.i3GLMoJ87986@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72884.1082150570.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document 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, 16 Apr 2004 14:22:50 -0700 Folks, It would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 08:09:52 -0700 From: Yakov Rekhter To: idr@ietf.org cc: skh@nexthop.com Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG documen t Folks, We receive a request to accept draft-lange-flexible-bgp-communities-02.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 28, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21040 for ; Fri, 16 Apr 2004 17:39: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 1BEaxK-0008Qf-7A; Fri, 16 Apr 2004 17:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEao0-0005qb-RY for idr@optimus.ietf.org; Fri, 16 Apr 2004 17:23: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 RAA11133 for ; Fri, 16 Apr 2004 17:23:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEany-0002uo-JO for idr@ietf.org; Fri, 16 Apr 2004 17:23:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEan4-0002tI-00 for idr@ietf.org; Fri, 16 Apr 2004 17:22:27 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEamS-0002pR-00 for idr@ietf.org; Fri, 16 Apr 2004 17:21:48 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3GLLIl98120 for ; Fri, 16 Apr 2004 14:21:18 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3GLLDJ87448 for ; Fri, 16 Apr 2004 14:21:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404162121.i3GLLDJ87448@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72719.1082150473.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-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, 16 Apr 2004 14:21:13 -0700 Folks, During the Last Call it would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. Thanks in advance. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 13:36:09 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. - ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - - --OtherAccess-- - - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA00508 for ; Thu, 15 Apr 2004 17:26:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDke-0000s1-RP; Thu, 15 Apr 2004 16:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDfg-0008L6-EO for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:41:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25607; Thu, 15 Apr 2004 16:41:13 -0400 (EDT) Message-Id: <200404152041.QAA25607@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-09.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:41:13 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, et al. Filename : draft-ietf-idr-restart-09.txt Pages : 10 Date : 2004-4-15 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-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-restart-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: <2004-4-15153844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15153844.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA28841 for ; Thu, 15 Apr 2004 16:39:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDZe-0006R2-BF; Thu, 15 Apr 2004 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDSv-0005LU-CO for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:28:05 -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 QAA24964 for ; Thu, 15 Apr 2004 16:28:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDSt-0000FU-Hh for idr@ietf.org; Thu, 15 Apr 2004 16:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDS5-0000D2-00 for idr@ietf.org; Thu, 15 Apr 2004 16:27:14 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BEDRc-00008L-00 for idr@ietf.org; Thu, 15 Apr 2004 16:26:44 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 491B52D4868 for ; Thu, 15 Apr 2004 16:26:15 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23531-01 for ; Thu, 15 Apr 2004 16:26:00 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BC1E22D482C for ; Thu, 15 Apr 2004 16:26:00 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQjATT+r3Tcj5ZtS5KO1S3UzQ+QSAAJVH+g From: "Susan Hares" To: "Pekka Savola" , "Yakov Rekhter" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 15 Apr 2004 16:26:00 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA28841 Pekka: This is in my hat as an editor of the draft. Not in my co-chair hat. Can you clarify something here: 1) Your need - informing the remote peer of warning limits, stop receive limits, and drop limits and SNMP traps, logs etcs is the basis for the draft. 2) Providers we talk to had 2 cases: 1) creeping VPN prefix limits 2) dump of whole routing table The need to treat the two differently. 3) Set until changed - that's the rub The providers wanted to negotiate the capabilties and upgrade the capabilities without dropping the connect. Is that what you mean as well? If so, could you comment on what is complex. History: We started this out with capabilities on open, and dynamic capabilities. Due to some vendor's request to include other mechanism (ORF, Soft Notify) to support the dynamic features - we added the rest. Other service providers said, Love the function but could you do it by prefix lengths. In an effort to get something working for all these folks, we made these other features optional. What part don't you like? Cause everything you stated you wanted -- is the basic part of the initial draft? Did you dis-like the additions (ORF, Soft Notify) and or the optional sub-codes? Do you think we should go back to the initial draft simplistic model? Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, April 15, 2004 11:29 AM To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document On Thu, 15 Apr 2004, Yakov Rekhter wrote: > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. The applicability does not seem to be sufficiently clear. That is, people use prefix limits for a *reason*. Once set, they're set until they are changed. There's no urgent need to specify anything here. However, I agree that it might not hurt to have some option that could be used to inform the peer on your limits, so that: - the operator of the peer could notice this when examining the neighbor's info (i.e., when contemplating about advertising new prefixes), or - if the peer exceeded the prefix limits, the peer's operator would notice that a warning/stop threshold has been reached (this could result in an SNMP trap, flashing led, or whatever.) I fail to see a need for anything more than that, and the current document *seems* to be more complex than that. Unless I'm mistaken, I'm not sure if going forward with this draft is a good idea. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA28385 for ; Thu, 15 Apr 2004 16:26:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDLB-0003ff-9T; Thu, 15 Apr 2004 16:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDBO-0001Ob-So for idr@optimus.ietf.org; Thu, 15 Apr 2004 16:09:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23737 for ; Thu, 15 Apr 2004 16:09:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDBN-00076g-2s for idr@ietf.org; Thu, 15 Apr 2004 16:09:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDAR-00072d-00 for idr@ietf.org; Thu, 15 Apr 2004 16:09:00 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BED9d-0006wb-00 for idr@ietf.org; Thu, 15 Apr 2004 16:08:09 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D30D62D4856 for ; Thu, 15 Apr 2004 16:05:44 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22604-03-6 for ; Thu, 15 Apr 2004 16:05:29 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 344222D4864 for ; Thu, 15 Apr 2004 16:05:29 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Message-ID: Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Thread-Index: AcQjJH5Ea3lSLG06TrGjjOWZyyaGsgAAC1hQ From: "Susan Hares" To: "Jeff Barrows" , "Pekka Savola" Cc: "Yakov Rekhter" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 15 Apr 2004 16:05:29 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA28385 Jeff: As an editor of the draft, I'd like a little bit more detail on what you think exceeds the level of effort or complexity. The three parameters (warning, stop receive, drop) [sub-codes 1-3] or the additional parameters (sub-codes 4,5,6,etc). Sue PS - the additional pieces were put in response to a discussion at the IETF. -----Original Message----- From: Jeff Barrows [mailto:jsb@barrows.net] Sent: Thursday, April 15, 2004 1:01 PM To: Pekka Savola Cc: Yakov Rekhter; idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document Not to limit cool/smart thinking, but I believe that the level of effort and/or complexity here exceeds the return. This has never been an issue in any of the major SP networks that I've played with. While protecting at the edges is of interest, sharing or communicating policy [such as thresholds] has been more of an area of concern (risk-wise) than a priority. An e-mail, phone call, or contractual arrangement should suffice in other cases. - jsb > Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) > From: Pekka Savola > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > On Thu, 15 Apr 2004, Yakov Rekhter wrote: > > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > > as an IDR WG document. Please send comments to the list. The deadline > > for comments is April 29, 2004. > > The applicability does not seem to be sufficiently clear. > > That is, people use prefix limits for a *reason*. Once set, they're > set until they are changed. There's no urgent need to specify > anything here. > > However, I agree that it might not hurt to have some option that could > be used to inform the peer on your limits, so that: > - the operator of the peer could notice this when examining the > neighbor's info (i.e., when contemplating about advertising new > prefixes), or > - if the peer exceeded the prefix limits, the peer's operator would > notice that a warning/stop threshold has been reached (this could > result in an SNMP trap, flashing led, or whatever.) > > I fail to see a need for anything more than that, and the current > document *seems* to be more complex than that. > > Unless I'm mistaken, I'm not sure if going forward with this draft is > a good idea. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA27637 for ; Thu, 15 Apr 2004 16:03: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 1BECyr-0007ZG-5p; Thu, 15 Apr 2004 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAF8-0006sO-TA for idr@optimus.ietf.org; Thu, 15 Apr 2004 13:01:38 -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 NAA04895 for ; Thu, 15 Apr 2004 13:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAF7-0007cs-00 for idr@ietf.org; Thu, 15 Apr 2004 13:01:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAEK-0007UH-00 for idr@ietf.org; Thu, 15 Apr 2004 13:00:48 -0400 Received: from gizmo.fireflynetworks.net ([207.76.173.57]) by ietf-mx with esmtp (Exim 4.12) id 1BEADO-0007Jl-00 for idr@ietf.org; Thu, 15 Apr 2004 12:59:51 -0400 Received: from jb.colo.dca.webact.com (jb.colo.dca.webact.com [207.76.173.57]) by gizmo.fireflynetworks.net (8.12.11/8.12.11) with ESMTP id i3FH0jO8094320; Thu, 15 Apr 2004 13:00:45 -0400 (EDT) (envelope-from jsb@barrows.net) From: Jeff Barrows X-X-Sender: jsb@gizmo.fireflynetworks.net To: Pekka Savola cc: Yakov Rekhter , Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: Message-ID: <20040415124633.I87123-100000@gizmo.fireflynetworks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, 15 Apr 2004 13:00:45 -0400 (EDT) Not to limit cool/smart thinking, but I believe that the level of effort and/or complexity here exceeds the return. This has never been an issue in any of the major SP networks that I've played with. While protecting at the edges is of interest, sharing or communicating policy [such as thresholds] has been more of an area of concern (risk-wise) than a priority. An e-mail, phone call, or contractual arrangement should suffice in other cases. - jsb > Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST) > From: Pekka Savola > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG > document > > On Thu, 15 Apr 2004, Yakov Rekhter wrote: > > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > > as an IDR WG document. Please send comments to the list. The deadline > > for comments is April 29, 2004. > > The applicability does not seem to be sufficiently clear. > > That is, people use prefix limits for a *reason*. Once set, they're > set until they are changed. There's no urgent need to specify > anything here. > > However, I agree that it might not hurt to have some option that could > be used to inform the peer on your limits, so that: > - the operator of the peer could notice this when examining the > neighbor's info (i.e., when contemplating about advertising new > prefixes), or > - if the peer exceeded the prefix limits, the peer's operator would > notice that a warning/stop threshold has been reached (this could > result in an SNMP trap, flashing led, or whatever.) > > I fail to see a need for anything more than that, and the current > document *seems* to be more complex than that. > > Unless I'm mistaken, I'm not sure if going forward with this draft is > a good idea. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22281 for ; Thu, 15 Apr 2004 13:29: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 1BEAWy-0002wH-7l; Thu, 15 Apr 2004 13:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAMg-0000qG-M4 for idr@optimus.ietf.org; Thu, 15 Apr 2004 13:09:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05369 for ; Thu, 15 Apr 2004 13:09:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAMe-0000lw-00 for idr@ietf.org; Thu, 15 Apr 2004 13:09:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEALf-0000e0-00 for idr@ietf.org; Thu, 15 Apr 2004 13:08:25 -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 1BEAKj-0000Sc-00 for idr@ietf.org; Thu, 15 Apr 2004 13:07:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2004 09:17:27 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3FH6p7t029487; Thu, 15 Apr 2004 10:06:51 -0700 (PDT) Received: from cisco.com (keyupate-lnx.cisco.com [128.107.163.249]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ARI16143; Thu, 15 Apr 2004 10:05:06 -0700 (PDT) Message-ID: <407EC12A.6040109@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: Alex Zinin CC: idr@ietf.org Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt References: <513361939.20040414192319@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: Thu, 15 Apr 2004 10:06:50 -0700 Alex: Thanks for the comments. We will incorporate them. -Keyur Alex Zinin wrote: >Folks- > >I have some technical comments regarding periods of stability and instability in >the Internet, BGP steady state, and the security considerations, plus several >editorial remarks. > >See inline below, please. > > > >>2.1. Key Features >> >> >... > > >> One of the most important path attributes is the Autonomous System >> Path, or AS_PATH. AS reachability information traverses the >> >> > ^^ > "As" > > > >> Internet, this information is augmented by the list of autonomous >> systems that have been traversed thus far, forming the AS_PATH. The >> AS_PATH allows straightforward suppression of the looping of routing >> information. In addition, the AS_PATH serves as a powerful and >> versatile mechanism for policy-based routing. >> >> BGP enhances the AS_PATH attribute to include sets of autonomous >> systems as well as lists via the AS_SET attribute. This extended >> format allows generated aggregate routes to carry path information >> from the more specific routes used to generate the aggregate. It >> should be noted however, that as of this writing, AS_SETs are rarely >> used in the Internet [ROUTEVIEWS]. >> >> >> >>2.2. BGP Algorithms >> >> >> BGP uses an algorithm that is neither a pure distance vector >> algorithm or a pure link state algorithm. It is instead a modified >> distance vector algorithm referred to as a "Path Vector" algorithm >> that uses path information to avoid traditional distance vector >> problems. Each route within BGP pairs destination with path >> information to that destination. Path information (also known as >> AS_PATH information) is stored within the AS_PATH attribute in BGP. >> This allows BGP to reconstruct large portions of overall topology >> whenever required. >> >> > >I've always been uncomfortable with documents saying that BGP reconstructs the >overall topology. It doesn't really do this like the link-state protocols do, >for example. > > > >> BGP uses an incremental update strategy in order to conserve >> bandwidth and processing power. That is, after initial exchange of >> complete routing information, a pair of BGP routers exchanges only >> changes to that information. Such an incremental update design >> requires reliable transport between a pair of BGP routers to function >> correctly. BGP solves this problem by using TCP for reliable >> transport. >> >> > >Should also note that use of TCP as the transport mechanism helps control >congestion and CPU utilization. > > > >> In addition to incremental updates, BGP has added the concept of >> route aggregation so that information about groups of networks may be >> >> >> >>Meyer and Patel Section 2.2. [Page 5] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> aggregated and sent as a single Network Layer Reachability (NLRI). >> >> > >this doesn't read well. Neither "reachability" nor "information" are countable. >"Single prefix" instead? > > > >> Finally, note that BGP is a self-contained protocol. That is, BGP >> specifies how routing information is exchanged both between BGP >> speakers in different autonomous systems, and between BGP speakers >> within a single autonomous system. >> >> >> >>2.3. BGP Finite State Machine (FSM) >> >> >> The BGP FSM is a set of rules that are applied to a BGP speaker's set >> of configured peers for the BGP operation. A BGP implementation >> requires that a BGP speaker must connect to and listen on TCP port >> 179 for accepting any new BGP connections from its peers. The BGP >> Finite State Machine, or FSM, must be initiated and maintained for >> each new incoming and outgoing peer connections. However, in steady >> state operation, there will be only one BGP FSM per connection per >> peer. >> >> There may exist a temporary period where in a BGP peer may have >> separate incoming and outgoing connections resulting into two >> different BGP FSMs for a peer (instead of one). This can be resolved >> following BGP connection collision rules defined in the [BGP4]. >> >> Following are different states of BGP FSM for its peers: >> >> IDLE: State when BGP peer refuses any incoming >> connections. >> >> CONNECT: State in which BGP peer is waiting for >> its TCP connection to be completed. >> >> ACTIVE: State in which BGP peer is trying to acquire a >> peer by listening and accepting TCP connection. >> >> OPENSENT: BGP peer is waiting for OPEN message from its >> peer. >> >> OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION >> message from its peer. >> >> ESTABLISHED: BGP peer connection is established and exchanges >> UPDATE, NOTIFICATION, and KEEPALIVE messages with >> its peer. >> >> There are different BGP events that operate on above mentioned states >> >> >> >>Meyer and Patel Section 2.3. [Page 6] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> of BGP FSM for its peers. These BGP events are used for initiating and >> terminating peer connections. They also assist BGP in identifying any >> persistent peer connection oscillations and provide a mechanism >> for controlling them. >> >> Following are different BGP events: >> >> Manual Start: Manually start the peer connection. >> >> Manual Stop: Manually stop the peer connection. >> >> Automatic Start: Local system automatically starts the peer >> connection. >> >> Manual start with >> passive TCP flag: Local system administrator manually starts the >> peer connection with peer in passive mode. >> >> Automatic start >> with passive TCP flag: Local system administrator automatically starts >> the peer connection with peer in passive mode. >> >> Automatic start >> with bgp_stop_flap >> option set: Local system administrator automatically starts >> the peer connection with peer oscillation >> damping enabled. >> >> Automatic start with >> bgp_stop_flap option >> set and passive TCP >> establishment >> option set: Local system administrator automatically starts >> the peer connection with peer oscillation >> damping enabled and with peer in passive mode. >> >> Automatic stop: Local system automatically stops the >> BGP connection. >> >> Both, Manual Start and Manual Stop are mandatory BGP events. All >> other events are optional. >> >> >> > >Ummmm... the above are "administrative" events only. There are other events in >the FSM, and most of other events are mandatory. > > > >> >> >> >> >> >> >>Meyer and Patel Section 2.3. [Page 7] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >>3. BGP Capabilities >> >> >> The BGP Capability mechanism [RFC2842] provides an easy and flexible >> way to introduce new features within the protocol. In particular, >> the BGP capability mechanism allows peers to negotiate various >> optional features during startup. This allows the base BGP protocol >> to contain only essential functionality, while at the same time >> providing a flexible mechanism for signaling protocol extensions. >> >> >> >>4. BGP Persistent Peer Oscillations >> >> >> Ideally, whenever a BGP speaker detects an error in any peer >> connection, it shuts down the peer and changes its FSM state to IDLE. >> BGP speaker requires a Start event to re-initiate its idle peer >> connection. If the error remains persistent and BGP speaker >> generates Start event automatically then it may result in persistent >> peer flapping. However, although peer oscillation is found to be >> wide-spread in BGP implementations, methods for preventing persistent >> peer oscillations are outside the scope of base BGP protocol >> specification. >> >> >> >>5. Implementation Guidelines >> >> >> A robust BGP implementation is work conserving. This means that if >> the number of prefixes is bound, arbitrarily high levels of route >> change can be tolerated with bounded impact on route convergence for >> occasionally changes in generally stable routes. >> >> > >"occasional"? > > > >> A BGP implementation under high load conditions should empty as much >> inbound routing updates from its input streams, processing only the >> most recent route if the route for a given NLRI changes multiple >> times. TCP also provides blocking on the writes on the sender side. >> A BGP implementation under load should expect blocks on write calls >> and send only the most recent routes when sockets unblock rather than >> sending entire history. >> >> A robust implementation of BGP should have the following >> characteristics: >> 1. It is able to operate in almost arbitrarily high levels >> of route flap without loosing peerings (failing to send >> keepalives) or loosing other protocol adjacencies as a >> >> >> >>Meyer and Patel Section 5. [Page 8] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> result of BGP load. >> >> 2. Instability of a subset of routes should not affect the >> route advertisements or forwarding associated with the set >> of stable routes. >> >> 3. High levels of instability and peers of different CPU speed >> or load resulting in faster or slower processing of routes >> should not cause instability and should have a bounded >> impact on the convergence time for generally stable routes. >> >> Numerous robust BGP implementations exist. Producing a robust >> implementation is not a trivial matter but clearly achievable. >> >> >> >> >>6. BGP Performance characteristics and Scalability >> >> >> In this section, we provide "order of magnitude" answers to the >> questions of how much link bandwidth, router memory and router CPU >> cycles the BGP protocol will consume under normal conditions. In >> particular, we will address the scalability of BGP and its >> limitations. >> >> >> >>6.1. Link bandwidth and CPU utilization >> >> >> Immediately after the initial BGP connection setup, BGP peers >> exchange complete set of routing information. If we denote the total >> number of routes in the Internet by N, the mean AS distance of the >> Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths by A, and assume that the networks are >> uniformly distributed among the autonomous systems, then the worst >> case amount of bandwidth consumed during the initial exchange between >> a pair of BGP speakers is >> >> BW = O(N + (M * A)) >> >> The following table illustrates the typical amount of bandwidth >> consumed during the initial exchange between a pair of BGP speakers >> based on the above assumptions (ignoring bandwidth consumed by the >> BGP Header). For purposes of the estimates here, we will calculate >> BW = 4 * (N + (M * A)). >> >> >> >>Meyer and Patel Section 6.1. [Page 9] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> # NLRI Mean AS Distance # AS's Bandwidth (MR) >> ---------- ---------------- ------ ---------------- >> 40,000 15 400 184,000 bytes >> 100,000 10 10,000 800,000 bytes >> 120,000 10 15,000 1,080,000 bytes >> 140,000 15 20,000 1,760,000 bytes >> >> [note that most of this bandwidth is consumed by the NLRI exchange] >> >> > >Is the caption for column 3 correct? It says "# AS's", which reads as "number of >AS's" while it seems it should be the number of unique paths. > > >> BGP was created specifically to reduce the size of the set of NLRI >> entries which have to be carried and exchanged by border routers. >> The aggregation scheme, defined in RFC 1519 [RFC1519], describes the >> provider-based aggregation scheme in use in today's Internet. >> >> Due to the advantages of advertising a few large aggregate blocks >> instead of many smaller class-based individual networks, it is >> difficult to estimate the actual reduction in bandwidth and >> processing that BGP has provided over BGP-3. If we simply enumerate >> all aggregate blocks into their individual class-based networks, we >> would not take into account "dead" space that has been reserved for >> future expansion. The best metric for determining the success of >> BGP's aggregation is to sample the number NLRI entries in the >> globally connected Internet today and compare it to projected growth >> rates before BGP was deployed. >> >> At the time of this writing, the full set of exterior routes carried >> by BGP is approximately 120,000 network entries [ROUTEVIEWS]. >> >> >> >>6.1.1. CPU utilization >> >> >> An important and fundamental feature of BGP is that BGP's CPU >> utilization depends only on the stability of the Internet. If the >> Internet is stable, then the only link bandwidth and router CPU >> cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE >> messages. The KEEPALIVE messages are exchanged only between peers. >> The suggested frequency of the exchange is 30 seconds. The KEEPALIVE >> messages are quite short (19 octets), and require virtually no >> processing. As a result, the bandwidth consumed by the KEEPALIVE >> messages is about 5 bits/sec. Operational experience confirms that >> the overhead (in terms of bandwidth and CPU) associated with the >> KEEPALIVE messages should be viewed as negligible. >> >> During periods of Internet instability, changes to the reachability >> information are passed between routers in UPDATE messages. The >> >> > >While theoretically the text is correct and we could talk about periods of >stability and instability of the Internet, I wonder if this text is still >applicable from the practical perspective. I.e., the continuous churn that the >Internet BGP speakers experience ensures that they practically always have >something to process. > >Probably instead of talking about periods of "Internet stability" and "Internet >instability" we could talk about something like "periods of stable state among >BGP speakers when they do no have new updates to communicate to each other". > > > >>Meyer and Patel Section 6.1.1. [Page 10] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> greatest overhead per UPDATE message occurs when each UPDATE message >> contains only a single network. It should be pointed out that in >> practice routing changes exhibit strong locality with respect to the >> AS path. That is, routes that change are likely to have common AS >> path. In this case, multiple networks can be grouped into a single >> UPDATE message, thus significantly reducing the amount of bandwidth >> required (see also Appendix F.1 of [BGP4]). >> >> Since in the steady state the link bandwidth and router CPU cycles >> consumed by the BGP protocol are dependent only on the stability of >> the Internet, it follows that BGP should have no scaling problems in >> the areas of link bandwidth and router CPU utilization. >> >> > >Not sure I follow here. What is meant by the "steady state" here? If it means >convergence on a stable topology after the initial exchange of updates, then why >talk about "stability of the Internet"? In other words, if the Internet is >unstable then can we say that the BGP speakers are in steady state? In the lack >of topology changes, it seems that the consumption should instead depend on the >number of peers (affects KEEPALIVE processing) and the number of persistently >oscillating routes potentially present in the network... > > > >>This assumes >> that as the Internet grows, the overall stability of the inter-AS >> connectivity of the Internet can be controlled. >> >> > >please specify how it is assumed to be "controlled", e.g. through operational >practices. > > > >>In particular, while >> the size of the IPv4 Internet routing table is bounded by O(232 * M), >> >> > >232 or 2^32? > > > >> (where M is a slow-moving function describing the AS >> interconnectivity of the network), >> >> > >slow-moving or slow-growing? > > > >>no such bound can be formulated >> for the dynamic properties (i.e., stability) of BGP. Although, the >> dynamic properties of the network cannot be quantitatively bounded, >> they can be controlled within BGP. Beyond certain changes in the >> network, BGP can start to suppress such changes using BGP Route Flap >> Damping [RFC2439], pacing of its route updates, or BGP would be >> unable to keep up with the changes and force suppression of multiple >> changes over very short periods by causing the BGP peer socket to >> block on the sender. >> >> >> >>6.1.2. Memory requirements >> >> >> To quantify the worst case memory requirements for BGP, we denote the >> total number of networks in the Internet by N, the mean AS distance >> of the Internet by M (distance at the level of an autonomous system, >> expressed in terms of the number of autonomous systems), the total >> number of unique AS paths as A. Then the worst case memory >> requirements (MR) can be expressed as >> >> >> MR = O(N + (M * A)) >> >> >> Since a mean AS distance M is a slow moving function of the >> interconnectivity ("meshiness") of the Internet, for all practical >> purposes the worst case router memory requirements are on the order >> of the total number of networks in the Internet times the number of >> peers the local system is peering with. We expect that the total >> number of networks in the Internet will grow much faster than the >> >> >> >>Meyer and Patel Section 6.1.2. [Page 11] >> >>INTERNET-DRAFT Expires: March 2004 September 2003 >> >> >> average number of peers per router. As a result, BGP's memory >> scaling properties are linearly related to the total number of >> networks in the Internet. >> >> The following table illustrates typical memory requirements of a >> router running BGP. We denote average number of routes advertised by >> each peer as N, the total number of unique AS paths as A, the mean AS >> distance of the Internet as M (distance at the level of an autonomous >> system, expressed in terms of the number of autonomous systems), >> number of bytes required to store a route as R, and number of bytes >> required to store one AS in an AS path as P. It is assumed that each >> network is encoded as four bytes, each AS is encoded as two bytes, >> and each networks is reachable via some fraction of all of the peers >> (# BGP peers/per net). For purposes of the estimates here, we will >> calculate MR = ((N * R) + (M * A) * P) >> >> >> # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) >> ---------- ---------------- ------ ------------------- -------------- >> 100,000 20 3,000 20 1,040,000 >> 100,000 20 15,000 20 1,040,000 >> 120,000 10 15,000 100 75,000,000 >> 140,000 15 20,000 100 116,000,000 >> >> >> In analyzing BGP's memory requirements, we focus on the size of the >> forwarding table (and ignoring implementation details). In >> particular, we derive upper bounds for the size of the forwarding >> table. >> >> > >The above doesn't look like calculations for a forwarding table--the FIB doesn't >normally contact AS-PATH info or all possible paths to a destination. > > > >>11. Security Considerations >> >> >> This document presents an analysis of the BGP protocol and as such >> presents no new security implications for BGP. >> >> > >I'm afraid the IESG will expect to see some more here. Specifically, I would >suggest that the document talks about available security mechanisms, and the >analysis of how they affect processing overhead, BW, and scalability. >Certainly a pointer to the bgp-vuln document would be useful. > >Alex > > >_______________________________________________ >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 (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20645 for ; Thu, 15 Apr 2004 12:42:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9jZ-0005Zv-BV; Thu, 15 Apr 2004 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9QO-0005bX-0u for idr@optimus.ietf.org; Thu, 15 Apr 2004 12: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 ESMTP id MAA02182 for ; Thu, 15 Apr 2004 12:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9QM-00024H-00 for idr@ietf.org; Thu, 15 Apr 2004 12:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9PQ-0001zq-00 for idr@ietf.org; Thu, 15 Apr 2004 12:08:12 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BE9OZ-0001rP-00 for idr@ietf.org; Thu, 15 Apr 2004 12:07:19 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3FG6bB08123; Thu, 15 Apr 2004 12:06:37 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29RLKQ9V; Thu, 15 Apr 2004 12:06:36 -0400 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JX6Z; Thu, 15 Apr 2004 12:06:36 -0400 Message-ID: <407EB30C.5040007@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 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: Thu, 15 Apr 2004 12:06:36 -0400 Hi Pekka , Pekka Savola wrote: >I fail to see a need for anything more than that, and the current >document *seems* to be more complex than that. > >Unless I'm mistaken, I'm not sure if going forward with this draft is > > >a good idea. > The draft addresses the issue described on a per AFI/SAFI pair and hence the need for additional mechanism. The requirement for different limits has come from the SPs which is why that is included. Thats the reason for tailoring the mechanism around it. srikanth chavali _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18742 for ; Thu, 15 Apr 2004 11:48: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 1BE8xB-0005wb-9P; Thu, 15 Apr 2004 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8pf-0003oF-QG for idr@optimus.ietf.org; Thu, 15 Apr 2004 11:31:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00785 for ; Thu, 15 Apr 2004 11:31:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8pe-0006Sc-00 for idr@ietf.org; Thu, 15 Apr 2004 11:31:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8oj-0006M2-00 for idr@ietf.org; Thu, 15 Apr 2004 11:30:17 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8nv-00068L-00 for idr@ietf.org; Thu, 15 Apr 2004 11:29:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3FFSl016149; Thu, 15 Apr 2004 18:28:47 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document In-Reply-To: <200404151359.i3FDxsJ92103@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 15 Apr 2004 18:28:47 +0300 (EEST) On Thu, 15 Apr 2004, Yakov Rekhter wrote: > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt > as an IDR WG document. Please send comments to the list. The deadline > for comments is April 29, 2004. The applicability does not seem to be sufficiently clear. That is, people use prefix limits for a *reason*. Once set, they're set until they are changed. There's no urgent need to specify anything here. However, I agree that it might not hurt to have some option that could be used to inform the peer on your limits, so that: - the operator of the peer could notice this when examining the neighbor's info (i.e., when contemplating about advertising new prefixes), or - if the peer exceeded the prefix limits, the peer's operator would notice that a warning/stop threshold has been reached (this could result in an SNMP trap, flashing led, or whatever.) I fail to see a need for anything more than that, and the current document *seems* to be more complex than that. Unless I'm mistaken, I'm not sure if going forward with this draft is a good idea. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15837 for ; Thu, 15 Apr 2004 10:24:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7dv-0008K0-AK; Thu, 15 Apr 2004 10:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7TP-00028y-F7 for idr@optimus.ietf.org; Thu, 15 Apr 2004 10:04: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 KAA24633 for ; Thu, 15 Apr 2004 10:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7TN-0005KN-00 for idr@ietf.org; Thu, 15 Apr 2004 10:04:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7SW-0005Fe-00 for idr@ietf.org; Thu, 15 Apr 2004 10:03:17 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Rd-00056o-00 for idr@ietf.org; Thu, 15 Apr 2004 10:02:21 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3FE1mo04788 for ; Thu, 15 Apr 2004 10:01:48 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29RLKK0M; Thu, 15 Apr 2004 10:01:47 -0400 Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JXWC; Thu, 15 Apr 2004 10:01:47 -0400 Message-ID: <407E95C2.3070901@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Srikanth Chavali User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: multipart/mixed; boundary="------------080105020709010800040801" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTML_TITLE_EMPTY autolearn=no version=2.60 Subject: [Idr] [Fwd: I-D ACTION:draft-chavali-bgp-prefixlimit-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: Thu, 15 Apr 2004 10:01:38 -0400 This is a multi-part message in MIME format. --------------080105020709010800040801 Content-Type: multipart/alternative; boundary="------------020505080408090500090101" --------------020505080408090500090101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI: -------- Original Message -------- Subject: I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt Date: Mon, 12 Apr 2004 15:31:26 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Peer Prefix Limits Exchange in BGP Author(s) : V. Radoaca, et al. Filename : draft-chavali-bgp-prefixlimit-01.txt Pages : 14 Date : 2004-4-12 This document proposes a mechanism to allow BGP peers to coordinate the setting of a limit on the number of prefixes which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding of routes, which can occur when a maximum prefix limit is configured on the 'receiving' peer, and the 'sending' peer exceeds the limit. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-chavali-bgp-prefixlimit-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-chavali-bgp-prefixlimit-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. --------------020505080408090500090101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit FYI:

-------- Original Message --------
Subject: I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt
Date: Mon, 12 Apr 2004 15:31:26 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Peer Prefix Limits Exchange in BGP
	Author(s)	: V. Radoaca, et al.
	Filename	: draft-chavali-bgp-prefixlimit-01.txt
	Pages		: 14
	Date		: 2004-4-12
	
This document proposes a mechanism to allow BGP peers to coordinate
the setting of a limit on the number of prefixes which one BGP
speaker will send to its peer.  Coordination can prevent disruption
of the peering session or discarding of routes, which can occur when
a maximum prefix limit is configured on the 'receiving' peer, and the
'sending' peer exceeds the limit.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-chavali-bgp-prefixlimit-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-chavali-bgp-prefixlimit-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.
--------------020505080408090500090101-- --------------080105020709010800040801 Content-Type: Message/External-body; name="draft-chavali-bgp-prefixlimit-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chavali-bgp-prefixlimit-01.txt" Content-Transfer-Encoding: 7bit --------------080105020709010800040801-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15640 for ; Thu, 15 Apr 2004 10:20: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 1BE7dt-0008J9-O7; Thu, 15 Apr 2004 10:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7RQ-0008RO-8Q for idr@optimus.ietf.org; Thu, 15 Apr 2004 10:02: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 KAA24501 for ; Thu, 15 Apr 2004 10:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7RO-00059Y-00 for idr@ietf.org; Thu, 15 Apr 2004 10:02:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7QT-00055l-00 for idr@ietf.org; Thu, 15 Apr 2004 10:01:10 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Pr-0004xP-00 for idr@ietf.org; Thu, 15 Apr 2004 10:00:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3FDxxl84207 for ; Thu, 15 Apr 2004 06:59:59 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3FDxsJ92103 for ; Thu, 15 Apr 2004 06:59:54 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404151359.i3FDxsJ92103@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92039.1082037594.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document 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, 15 Apr 2004 06:59:54 -0700 Folks, We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 29, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15447 for ; Thu, 15 Apr 2004 10:13: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 1BE7MU-0005HY-PO; Thu, 15 Apr 2004 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Fw-0003dR-V5 for idr@optimus.ietf.org; Thu, 15 Apr 2004 09:50:17 -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 JAA23910 for ; Thu, 15 Apr 2004 09:50:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Fv-00048I-00 for idr@ietf.org; Thu, 15 Apr 2004 09:50:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7FH-00043S-00 for idr@ietf.org; Thu, 15 Apr 2004 09:49:36 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Eh-0003wG-00; Thu, 15 Apr 2004 09:48:59 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3FDmRl84173; Thu, 15 Apr 2004 06:48:27 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3FDmMJ91101; Thu, 15 Apr 2004 06:48:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404151348.i3FDmMJ91101@merlot.juniper.net> To: zinin@psg.com, fenner@research.att.com cc: idr@ietf.org, iesg-secretary@ietf.org, skh@nexthop.com, yakov@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89571.1082036871.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] BGP Cease subcodes to Proposed Standard 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, 15 Apr 2004 06:48:22 -0700 Alex and Bill, The IDR WG would like to ask the IESG to advance BGP Cease Subcodes (draft-ietf-idr-cease-subcode-04.txt) to a Proposed Standard. The implementation report is in draft-chen-bgp-cease-subcode-survey-00.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA14662 for ; Thu, 15 Apr 2004 09:54: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 1BE7Dn-0002cK-Nq; Thu, 15 Apr 2004 09:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE783-0000Dh-B3 for idr@optimus.ietf.org; Thu, 15 Apr 2004 09:42:07 -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 JAA23443 for ; Thu, 15 Apr 2004 09:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE781-0003Gy-00 for idr@ietf.org; Thu, 15 Apr 2004 09:42:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE772-0003Be-00 for idr@ietf.org; Thu, 15 Apr 2004 09:41:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BE763-00033K-00 for idr@ietf.org; Thu, 15 Apr 2004 09:40:03 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EBC532D4848 for ; Thu, 15 Apr 2004 09:39:32 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13783-01-25 for ; Thu, 15 Apr 2004 09:39:20 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 066EA2D4834 for ; Thu, 15 Apr 2004 09:39:20 -0400 (EDT) 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: draft-chavali-bgp-prefixlimit-01.txt Thread-Index: AcQi7w3l0C/aXkMNTJaWNIxQs7XfjQ== From: "Susan Hares" To: Cc: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-chavali-bgp-prefixlimit-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: Thu, 15 Apr 2004 09:39:19 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA14662 I would like to request this this draft becoming a working group draft. Discussion during IETF 58, indicated there was interest from service providers to having this become a working group draft. Sue ---------- Title : Peer Prefix Limits Exchange in BGP Author(s) : V. Radoaca, et al. Filename : draft-chavali-bgp-prefixlimit-01.txt Pages : 14 Date : 2004-4-12 Abstract: This document proposes a mechanism to allow BGP peers to coordinate the setting of a lmit on the number of prefix which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding of routes, which can occur when a maximum prefix limit is configured on the "receiving" peer, and the "sending" peer exceeds the limit. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA21425 for ; Wed, 14 Apr 2004 23:05:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx5h-0006qW-QJ; Wed, 14 Apr 2004 22: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 1BDx3l-0006AV-2O for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:57: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 WAA12926 for ; Wed, 14 Apr 2004 22:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx3h-0001pp-00 for idr@ietf.org; Wed, 14 Apr 2004 22:56:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDx3I-0001mG-00 for idr@ietf.org; Wed, 14 Apr 2004 22:56:32 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDx2D-0001jb-00 for idr@ietf.org; Wed, 14 Apr 2004 22:55:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDx2E-000O3x-6T for idr@ietf.org; Thu, 15 Apr 2004 02:55:26 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <953258565.20040414195525@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp4-experience-protocol-03.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 19:55:25 -0700 Folks- I'm generally quite happy with this document. The only comment I had was about the way the 2119 requirements language is used. In some places (simple search for "MUST" would reveal), the document reads as defining protocol procedures, which should be in the protocol spec. If the intention is to quote the spec, the wording should be changed accordingly. Refs to SBGP and SoBGP should be filled in. Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA20826 for ; Wed, 14 Apr 2004 22:48:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwt7-0003tC-Dj; Wed, 14 Apr 2004 22:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDwr0-0003JS-TX for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:43: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 WAA12573 for ; Wed, 14 Apr 2004 22:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwqx-00016u-00 for idr@ietf.org; Wed, 14 Apr 2004 22:43:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwq1-00013U-00 for idr@ietf.org; Wed, 14 Apr 2004 22:42:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDwp6-00010H-00 for idr@ietf.org; Wed, 14 Apr 2004 22:41:52 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDwp6-000LFs-SJ for idr@ietf.org; Thu, 15 Apr 2004 02:41:52 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1778578854.20040414194151@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-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, 14 Apr 2004 19:41:51 -0700 Folks- Several comments inline below. > 1.1 General > > This draft of BGP-4 attempts to bring BGP standard as described in Seems like this is out of context. > RFC 1771 in alignment with the deployments of the BGP-4 protocols. > The changes with RFC 1771 are listed in the appendix A of[BGP4]. > BGP-4 as deployed in the Internet encompasses both this base > specification and additional specifications such as TCP MD5 > [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations > [RFC3065], and BGP Route Refresh [RFC 2918]. > > BGP as a widely deployed cornerstone of Internet technology > continues to add additional functionality as the needs within the > Internet require. This survey had 259 detailed questions on the > compliances with the standard. 3 implementers (Cisco, Laurel, > NextHop) sent in implementation reports. Sections X - Y provides > the compilation of those results. > > X implementers who responded below indicating inter-operability with > other implementations. Of these X implementations, Y also indicated > the length of the survey was as problem. The editor recommends that > other methods, such as enlisting existing testing vendors be > employed to gather more implementation report. > > Section Z provides the quick survey results on inter-operability. > > > > Hares & Retana Expires - August 2004 [Page 3] > > > > > draft-ietf-idr-bgp-implementation-00 February 2004 > > X, Y, and Z need to be filled out... ;) > 1.2 Full Survey result summary > > Significant Differences > > All 259 survey points had two "y" or "y" and "O" except the > following: At this point of the document, it is not clear what "y" and "0" are. > Generally, if we don't have at least two implementations for a specific feature, it can't stay in the spec. The granularity of the BGP implementation report is finer than on a per-feature basis, but we still need to see if the spec needs to be fixed accordingly. More specific comments below: > MUST - Question 214 > > Question 214 about aggregation of routes. section 9.1.4 had a "N" > response from 3 implementers indicating that they install both > routes, and 1 yes. when I look at section 2.43.214, I see: Alcatel Y/N/O/Comments: Y Cisco Y/N/O/Comments: Y Laurel Y/N/O/Comments: Y NextHop Y/N/O/Comments: Y wrong section? > SHALL NOT - Question 228, regarding section 9.2.2.2 > > Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall not > (meaning they did). One vendor (NextHop) indicate "y" matching > the specification. > > text: Routes that have different MULTI_EXIT_DISC attribute SHALL > NOT be aggregated. If this is considered to be important for protocol correctness, then the WG may consider softening the requirements language and changing it to "SHOULD NOT"--apparently some implementers found that under certain circumstances such routes still need to be aggregated. > SHOULD - 2 in appendix F (questions 257, 258) > > Three vendors said no, one vendor said yes to question 257. All > four vendors indicated no to question 258. (Please note that > Appendix F is an optional text section) > > Text: section F.2 - A BGP speaker which needs to withdraw a > destination and send an update about a more specific or less > specific route SHOULD combine them into the same UPDATE message. > > Text: Section F.6: The last instance (rightmost occurrence) of > that AS number is kept. Assuming that the appendices are not a normative part of the spec, the 2119 language should not be used there. ... > 1.4 Implementations and interoperability > > Short informal summary of implementers reporting implementations and > inter-operability > > [This section will be added later but will have the format below ] > > Alcatel Cisco Laurel NextHop > Alcatel > Cisco > Laurel > NextHop the above table needs to be filled out. > 1.5 BGP Implementation Identification This section does not specify the origin of code > 1.5.0 Alcatel > > 1.5.1 Cisco > Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S > Date: 11/26/2003 > > 1.5.2 Laurel > > 1.5.3 NextHop Technologies > Implementation Name/Version: Gated NGC 2.0, 2.2 > Date: January 2004 > > > Hares & Retana Expires - August 2004 [Page 5] > > > > > draft-ietf-idr-bgp-implementation-00 February 2004 > > > > 2. BGP4 Implementation Report > > For every item listed, the respondents indicated whether their > implementation supports the Functionality/Description or not (Y/N) > according to the RFC2119 [3] language indicated. "according to the RFC 2119" should probably be removed. The implementation either decides to support something the 2119 language prescribes in some form or it doesn't. > Any respondent > comments are included. If appropriate, the respondents indicated > with O the fact that the support is neither Y/N (an alternate > behavior, for example). Refer to the appropriate sections in the > latest BGP-4 ID [4] for additional details. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA20246 for ; Wed, 14 Apr 2004 22:31: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 1BDwbh-0007ou-BU; Wed, 14 Apr 2004 22: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 1BDwYb-0006yl-Nc for idr@optimus.ietf.org; Wed, 14 Apr 2004 22:24: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 WAA11925 for ; Wed, 14 Apr 2004 22:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDwYY-00006s-00 for idr@ietf.org; Wed, 14 Apr 2004 22:24:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwXd-00004U-00 for idr@ietf.org; Wed, 14 Apr 2004 22:23:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDwXA-000020-00 for idr@ietf.org; Wed, 14 Apr 2004 22:23:20 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDwXA-000Gc2-76 for idr@ietf.org; Thu, 15 Apr 2004 02:23:20 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <513361939.20040414192319@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 19:23:19 -0700 Folks- I have some technical comments regarding periods of stability and instability in the Internet, BGP steady state, and the security considerations, plus several editorial remarks. See inline below, please. > 2.1. Key Features ... > One of the most important path attributes is the Autonomous System > Path, or AS_PATH. AS reachability information traverses the ^^ "As" > Internet, this information is augmented by the list of autonomous > systems that have been traversed thus far, forming the AS_PATH. The > AS_PATH allows straightforward suppression of the looping of routing > information. In addition, the AS_PATH serves as a powerful and > versatile mechanism for policy-based routing. > > BGP enhances the AS_PATH attribute to include sets of autonomous > systems as well as lists via the AS_SET attribute. This extended > format allows generated aggregate routes to carry path information > from the more specific routes used to generate the aggregate. It > should be noted however, that as of this writing, AS_SETs are rarely > used in the Internet [ROUTEVIEWS]. > > > > 2.2. BGP Algorithms > > > BGP uses an algorithm that is neither a pure distance vector > algorithm or a pure link state algorithm. It is instead a modified > distance vector algorithm referred to as a "Path Vector" algorithm > that uses path information to avoid traditional distance vector > problems. Each route within BGP pairs destination with path > information to that destination. Path information (also known as > AS_PATH information) is stored within the AS_PATH attribute in BGP. > This allows BGP to reconstruct large portions of overall topology > whenever required. I've always been uncomfortable with documents saying that BGP reconstructs the overall topology. It doesn't really do this like the link-state protocols do, for example. > BGP uses an incremental update strategy in order to conserve > bandwidth and processing power. That is, after initial exchange of > complete routing information, a pair of BGP routers exchanges only > changes to that information. Such an incremental update design > requires reliable transport between a pair of BGP routers to function > correctly. BGP solves this problem by using TCP for reliable > transport. Should also note that use of TCP as the transport mechanism helps control congestion and CPU utilization. > > In addition to incremental updates, BGP has added the concept of > route aggregation so that information about groups of networks may be > > > > Meyer and Patel Section 2.2. [Page 5] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > aggregated and sent as a single Network Layer Reachability (NLRI). this doesn't read well. Neither "reachability" nor "information" are countable. "Single prefix" instead? > Finally, note that BGP is a self-contained protocol. That is, BGP > specifies how routing information is exchanged both between BGP > speakers in different autonomous systems, and between BGP speakers > within a single autonomous system. > > > > 2.3. BGP Finite State Machine (FSM) > > > The BGP FSM is a set of rules that are applied to a BGP speaker's set > of configured peers for the BGP operation. A BGP implementation > requires that a BGP speaker must connect to and listen on TCP port > 179 for accepting any new BGP connections from its peers. The BGP > Finite State Machine, or FSM, must be initiated and maintained for > each new incoming and outgoing peer connections. However, in steady > state operation, there will be only one BGP FSM per connection per > peer. > > There may exist a temporary period where in a BGP peer may have > separate incoming and outgoing connections resulting into two > different BGP FSMs for a peer (instead of one). This can be resolved > following BGP connection collision rules defined in the [BGP4]. > > Following are different states of BGP FSM for its peers: > > IDLE: State when BGP peer refuses any incoming > connections. > > CONNECT: State in which BGP peer is waiting for > its TCP connection to be completed. > > ACTIVE: State in which BGP peer is trying to acquire a > peer by listening and accepting TCP connection. > > OPENSENT: BGP peer is waiting for OPEN message from its > peer. > > OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION > message from its peer. > > ESTABLISHED: BGP peer connection is established and exchanges > UPDATE, NOTIFICATION, and KEEPALIVE messages with > its peer. > > There are different BGP events that operate on above mentioned states > > > > Meyer and Patel Section 2.3. [Page 6] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > of BGP FSM for its peers. These BGP events are used for initiating and > terminating peer connections. They also assist BGP in identifying any > persistent peer connection oscillations and provide a mechanism > for controlling them. > > Following are different BGP events: > > Manual Start: Manually start the peer connection. > > Manual Stop: Manually stop the peer connection. > > Automatic Start: Local system automatically starts the peer > connection. > > Manual start with > passive TCP flag: Local system administrator manually starts the > peer connection with peer in passive mode. > > Automatic start > with passive TCP flag: Local system administrator automatically starts > the peer connection with peer in passive mode. > > Automatic start > with bgp_stop_flap > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled. > > Automatic start with > bgp_stop_flap option > set and passive TCP > establishment > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled and with peer in passive mode. > > Automatic stop: Local system automatically stops the > BGP connection. > > Both, Manual Start and Manual Stop are mandatory BGP events. All > other events are optional. > Ummmm... the above are "administrative" events only. There are other events in the FSM, and most of other events are mandatory. > > > > > > > > > Meyer and Patel Section 2.3. [Page 7] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > 3. BGP Capabilities > > > The BGP Capability mechanism [RFC2842] provides an easy and flexible > way to introduce new features within the protocol. In particular, > the BGP capability mechanism allows peers to negotiate various > optional features during startup. This allows the base BGP protocol > to contain only essential functionality, while at the same time > providing a flexible mechanism for signaling protocol extensions. > > > > 4. BGP Persistent Peer Oscillations > > > Ideally, whenever a BGP speaker detects an error in any peer > connection, it shuts down the peer and changes its FSM state to IDLE. > BGP speaker requires a Start event to re-initiate its idle peer > connection. If the error remains persistent and BGP speaker > generates Start event automatically then it may result in persistent > peer flapping. However, although peer oscillation is found to be > wide-spread in BGP implementations, methods for preventing persistent > peer oscillations are outside the scope of base BGP protocol > specification. > > > > 5. Implementation Guidelines > > > A robust BGP implementation is work conserving. This means that if > the number of prefixes is bound, arbitrarily high levels of route > change can be tolerated with bounded impact on route convergence for > occasionally changes in generally stable routes. "occasional"? > > A BGP implementation under high load conditions should empty as much > inbound routing updates from its input streams, processing only the > most recent route if the route for a given NLRI changes multiple > times. TCP also provides blocking on the writes on the sender side. > A BGP implementation under load should expect blocks on write calls > and send only the most recent routes when sockets unblock rather than > sending entire history. > > A robust implementation of BGP should have the following > characteristics: > 1. It is able to operate in almost arbitrarily high levels > of route flap without loosing peerings (failing to send > keepalives) or loosing other protocol adjacencies as a > > > > Meyer and Patel Section 5. [Page 8] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > result of BGP load. > > 2. Instability of a subset of routes should not affect the > route advertisements or forwarding associated with the set > of stable routes. > > 3. High levels of instability and peers of different CPU speed > or load resulting in faster or slower processing of routes > should not cause instability and should have a bounded > impact on the convergence time for generally stable routes. > > Numerous robust BGP implementations exist. Producing a robust > implementation is not a trivial matter but clearly achievable. > > > > > 6. BGP Performance characteristics and Scalability > > > In this section, we provide "order of magnitude" answers to the > questions of how much link bandwidth, router memory and router CPU > cycles the BGP protocol will consume under normal conditions. In > particular, we will address the scalability of BGP and its > limitations. > > > > 6.1. Link bandwidth and CPU utilization > > > Immediately after the initial BGP connection setup, BGP peers > exchange complete set of routing information. If we denote the total > number of routes in the Internet by N, the mean AS distance of the > Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths by A, and assume that the networks are > uniformly distributed among the autonomous systems, then the worst > case amount of bandwidth consumed during the initial exchange between > a pair of BGP speakers is > > BW = O(N + (M * A)) > > The following table illustrates the typical amount of bandwidth > consumed during the initial exchange between a pair of BGP speakers > based on the above assumptions (ignoring bandwidth consumed by the > BGP Header). For purposes of the estimates here, we will calculate > BW = 4 * (N + (M * A)). > > > > Meyer and Patel Section 6.1. [Page 9] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > # NLRI Mean AS Distance # AS's Bandwidth (MR) > ---------- ---------------- ------ ---------------- > 40,000 15 400 184,000 bytes > 100,000 10 10,000 800,000 bytes > 120,000 10 15,000 1,080,000 bytes > 140,000 15 20,000 1,760,000 bytes > > [note that most of this bandwidth is consumed by the NLRI exchange] Is the caption for column 3 correct? It says "# AS's", which reads as "number of AS's" while it seems it should be the number of unique paths. > > BGP was created specifically to reduce the size of the set of NLRI > entries which have to be carried and exchanged by border routers. > The aggregation scheme, defined in RFC 1519 [RFC1519], describes the > provider-based aggregation scheme in use in today's Internet. > > Due to the advantages of advertising a few large aggregate blocks > instead of many smaller class-based individual networks, it is > difficult to estimate the actual reduction in bandwidth and > processing that BGP has provided over BGP-3. If we simply enumerate > all aggregate blocks into their individual class-based networks, we > would not take into account "dead" space that has been reserved for > future expansion. The best metric for determining the success of > BGP's aggregation is to sample the number NLRI entries in the > globally connected Internet today and compare it to projected growth > rates before BGP was deployed. > > At the time of this writing, the full set of exterior routes carried > by BGP is approximately 120,000 network entries [ROUTEVIEWS]. > > > > 6.1.1. CPU utilization > > > An important and fundamental feature of BGP is that BGP's CPU > utilization depends only on the stability of the Internet. If the > Internet is stable, then the only link bandwidth and router CPU > cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE > messages. The KEEPALIVE messages are exchanged only between peers. > The suggested frequency of the exchange is 30 seconds. The KEEPALIVE > messages are quite short (19 octets), and require virtually no > processing. As a result, the bandwidth consumed by the KEEPALIVE > messages is about 5 bits/sec. Operational experience confirms that > the overhead (in terms of bandwidth and CPU) associated with the > KEEPALIVE messages should be viewed as negligible. > > During periods of Internet instability, changes to the reachability > information are passed between routers in UPDATE messages. The While theoretically the text is correct and we could talk about periods of stability and instability of the Internet, I wonder if this text is still applicable from the practical perspective. I.e., the continuous churn that the Internet BGP speakers experience ensures that they practically always have something to process. Probably instead of talking about periods of "Internet stability" and "Internet instability" we could talk about something like "periods of stable state among BGP speakers when they do no have new updates to communicate to each other". > > Meyer and Patel Section 6.1.1. [Page 10] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > greatest overhead per UPDATE message occurs when each UPDATE message > contains only a single network. It should be pointed out that in > practice routing changes exhibit strong locality with respect to the > AS path. That is, routes that change are likely to have common AS > path. In this case, multiple networks can be grouped into a single > UPDATE message, thus significantly reducing the amount of bandwidth > required (see also Appendix F.1 of [BGP4]). > > Since in the steady state the link bandwidth and router CPU cycles > consumed by the BGP protocol are dependent only on the stability of > the Internet, it follows that BGP should have no scaling problems in > the areas of link bandwidth and router CPU utilization. Not sure I follow here. What is meant by the "steady state" here? If it means convergence on a stable topology after the initial exchange of updates, then why talk about "stability of the Internet"? In other words, if the Internet is unstable then can we say that the BGP speakers are in steady state? In the lack of topology changes, it seems that the consumption should instead depend on the number of peers (affects KEEPALIVE processing) and the number of persistently oscillating routes potentially present in the network... > This assumes > that as the Internet grows, the overall stability of the inter-AS > connectivity of the Internet can be controlled. please specify how it is assumed to be "controlled", e.g. through operational practices. > In particular, while > the size of the IPv4 Internet routing table is bounded by O(232 * M), 232 or 2^32? > (where M is a slow-moving function describing the AS > interconnectivity of the network), slow-moving or slow-growing? > no such bound can be formulated > for the dynamic properties (i.e., stability) of BGP. Although, the > dynamic properties of the network cannot be quantitatively bounded, > they can be controlled within BGP. Beyond certain changes in the > network, BGP can start to suppress such changes using BGP Route Flap > Damping [RFC2439], pacing of its route updates, or BGP would be > unable to keep up with the changes and force suppression of multiple > changes over very short periods by causing the BGP peer socket to > block on the sender. > > > > 6.1.2. Memory requirements > > > To quantify the worst case memory requirements for BGP, we denote the > total number of networks in the Internet by N, the mean AS distance > of the Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths as A. Then the worst case memory > requirements (MR) can be expressed as > > > MR = O(N + (M * A)) > > > Since a mean AS distance M is a slow moving function of the > interconnectivity ("meshiness") of the Internet, for all practical > purposes the worst case router memory requirements are on the order > of the total number of networks in the Internet times the number of > peers the local system is peering with. We expect that the total > number of networks in the Internet will grow much faster than the > > > > Meyer and Patel Section 6.1.2. [Page 11] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > average number of peers per router. As a result, BGP's memory > scaling properties are linearly related to the total number of > networks in the Internet. > > The following table illustrates typical memory requirements of a > router running BGP. We denote average number of routes advertised by > each peer as N, the total number of unique AS paths as A, the mean AS > distance of the Internet as M (distance at the level of an autonomous > system, expressed in terms of the number of autonomous systems), > number of bytes required to store a route as R, and number of bytes > required to store one AS in an AS path as P. It is assumed that each > network is encoded as four bytes, each AS is encoded as two bytes, > and each networks is reachable via some fraction of all of the peers > (# BGP peers/per net). For purposes of the estimates here, we will > calculate MR = ((N * R) + (M * A) * P) > > > # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) > ---------- ---------------- ------ ------------------- -------------- > 100,000 20 3,000 20 1,040,000 > 100,000 20 15,000 20 1,040,000 > 120,000 10 15,000 100 75,000,000 > 140,000 15 20,000 100 116,000,000 > > > In analyzing BGP's memory requirements, we focus on the size of the > forwarding table (and ignoring implementation details). In > particular, we derive upper bounds for the size of the forwarding > table. The above doesn't look like calculations for a forwarding table--the FIB doesn't normally contact AS-PATH info or all possible paths to a destination. > > 11. Security Considerations > > > This document presents an analysis of the BGP protocol and as such > presents no new security implications for BGP. I'm afraid the IESG will expect to see some more here. Specifically, I would suggest that the document talks about available security mechanisms, and the analysis of how they affect processing overhead, BW, and scalability. Certainly a pointer to the bgp-vuln document would be useful. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA11634 for ; Wed, 14 Apr 2004 18:24: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 1BDshk-000565-Q8; Wed, 14 Apr 2004 18:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsdj-0002yY-6q for idr@optimus.ietf.org; Wed, 14 Apr 2004 18:13: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 SAA01894 for ; Wed, 14 Apr 2004 18:13:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsdg-0001W1-00 for idr@ietf.org; Wed, 14 Apr 2004 18:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDscn-0001SY-00 for idr@ietf.org; Wed, 14 Apr 2004 18:12:53 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BDsc7-0001OU-00 for idr@ietf.org; Wed, 14 Apr 2004 18:12:11 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 08BC5912AE7; Wed, 14 Apr 2004 15:12:12 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20510-08; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 97210912AE4; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 47B6615D3C2; Wed, 14 Apr 2004 15:12:11 -0700 (PDT) To: idr@ietf.org Cc: enke@redback.com, yakov@juniper.net, skh@nexthop.com From: Enke Chen Message-Id: <20040414221211.47B6615D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] Implementation survey for BGP Route Reflection 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, 14 Apr 2004 15:12:11 -0700 Hi, folks: We need an implementation report to advance the BGP Route Reflection draft (draft-ietf-idr-rfc2796bis-00.txt). For folks who have done the implementation, could you fill out the simple survey (attached), and send to me by April 28, 2004? Thanks. -- Enke ------------------------------------------------------------------ Implementation Report for BGP Route Reflection (draft-ietf-idr-rfc2796bis-00.txt) Organization: Person filling out this form: Does your implementation follow the procedures specified in the Operation Section when advertising an IBGP learned route to an IBGP peer? Does your implementation recognize the two new attributes (ORIGINATOR_ID and CLUSTER_LIST) defined in the document? Does your implementation perform routing information loop detection based on the ORIGINATOR_ID and the CLUSTER_LIST attributes as specified in the document? Does your implementation format the two new attributes (ORIGINATOR_ID and CLUSTER_LIST) as specified in the document when doing route reflection? Does your implementation take the ORIGNATOR_ID and the CLUSTER_LIST attributes into account in route selection as specified in the document? List other implementations that you have tested for BGP Route Reflection interoperability. ---------------------------------------------------------------------------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA11317 for ; Wed, 14 Apr 2004 18:15:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsbz-00020Z-AB; Wed, 14 Apr 2004 18:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsXl-0008FK-Sd for idr@optimus.ietf.org; Wed, 14 Apr 2004 18:07:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01104 for ; Wed, 14 Apr 2004 18:07:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsXi-000192-00 for idr@ietf.org; Wed, 14 Apr 2004 18:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsX0-00015P-00 for idr@ietf.org; Wed, 14 Apr 2004 18:06:54 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BDsWP-00011e-00 for idr@ietf.org; Wed, 14 Apr 2004 18:06:17 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C3242912AF0; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19736-08; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 9F1C4912AEE; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 7F40115D3C2; Wed, 14 Apr 2004 15:06:16 -0700 (PDT) To: idr@ietf.org Cc: enke@redback.com From: Enke Chen Message-Id: <20040414220616.7F40115D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] I-D ACTION:draft-chen-bgp-cease-subcode-survey-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, 14 Apr 2004 15:06:16 -0700 FYI. -- Enke ------- Forwarded Message To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-cease-subcode-survey-00.txt Date: Wed, 14 Apr 2004 15:32:43 -0400 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Cease Subcode - Implementation Report Author(s) : E. Chen Filename : draft-chen-bgp-cease-subcode-survey-00.txt Pages : 4 Date : 2004-4-14 This document provides an implementation report for the BGP Cease Subcodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-cease-subcode-survey-00.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09981 for ; Wed, 14 Apr 2004 17:37: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 1BDrls-0005ld-U9; Wed, 14 Apr 2004 17:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrbp-0007v3-83 for idr@optimus.ietf.org; Wed, 14 Apr 2004 17:07: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 RAA26171 for ; Wed, 14 Apr 2004 17:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDraZ-0003oF-00 for idr@ietf.org; Wed, 14 Apr 2004 17:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrZa-0003kU-00 for idr@ietf.org; Wed, 14 Apr 2004 17:05:31 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDrYd-0003fe-00 for idr@ietf.org; Wed, 14 Apr 2004 17:04:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EL3tl80928; Wed, 14 Apr 2004 14:03:55 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EL3oJ91061; Wed, 14 Apr 2004 14:03:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142103.i3EL3oJ91061@merlot.juniper.net> To: Steve Bellovin cc: idr@ietf.org, Stephen Kent , Alex Zinin Subject: Re: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Thu, 08 Apr 2004 16:52:18 PDT." <5810329073.20040408165218@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46766.1081976630.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 14 Apr 2004 14:03:50 -0700 Steve, > This is a forwarded message > From: Steven M. Bellovin > To: Stephen Kent > Cc: Alex Zinin , saag@mit.edu > Date: Wednesday, April 7, 2004, 8:13:10 AM > Subject: [saag] draft-iesg-tcpmd5app-00.txt > > ===8<==============Original message text=============== > In message , Stephen Kent writes: > > >If you look at Steve's document, he uses the right terminology > >throughout, while referring to the document via its RFC number. > >That's a good model for any document that wants to avoid perpetuating > >the terminology error inherent in the title of 2385. > > > > It's probably worth putting a note in my document noting the erroneous > terminology in the title of 2385. It's not a bad idea having a similar > parenthetical note in the bgp document. Could you send me the note, so that I'll include it in the bgp doc. Thanks in advance. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09414 for ; Wed, 14 Apr 2004 17:23:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrfq-0002O0-9l; Wed, 14 Apr 2004 17:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrBa-0000uK-A2 for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23758 for ; Wed, 14 Apr 2004 16:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrBY-0000yS-00 for idr@ietf.org; Wed, 14 Apr 2004 16:40:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrAe-0000sv-00 for idr@ietf.org; Wed, 14 Apr 2004 16:39:44 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BDr9q-0000jP-00 for idr@ietf.org; Wed, 14 Apr 2004 16:38:54 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3EKcHBm050895; Wed, 14 Apr 2004 13:38:17 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKcHJ88016; Wed, 14 Apr 2004 13:38:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142038.i3EKcHJ88016@merlot.juniper.net> To: Stephen Kent cc: Alex Zinin , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 09 Apr 2004 11:40:58 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42356.1081975097.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 14 Apr 2004 13:38:17 -0700 Steve, > > > > > > > >Steve, would you mind making a suggestion on how the text could be improved? > >E.g., would a separate section in the main body of the document specifying > >the requirement for TCP-MD5 support be useful? > > A reasonable approach would be to have a section of the document that > describes the use of this TCP option. It should explain why/when one > would use the option in the context of BGP links and what protection > it offers. Would you please produce the appropriate text for this section. Thanks in advance. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09262 for ; Wed, 14 Apr 2004 17:20: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 1BDrfg-0002Cs-TP; Wed, 14 Apr 2004 17:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDr9b-00007t-EU for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:38:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23567 for ; Wed, 14 Apr 2004 16:38:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDr9Z-0000kz-00 for idr@ietf.org; Wed, 14 Apr 2004 16:38:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDr8c-0000eY-00 for idr@ietf.org; Wed, 14 Apr 2004 16:37:38 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDr7k-0000Wc-00 for idr@ietf.org; Wed, 14 Apr 2004 16:36:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EKaEl80825 for ; Wed, 14 Apr 2004 13:36:14 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKa9J87859 for ; Wed, 14 Apr 2004 13:36:09 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142036.i3EKa9J87859@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42084.1081974969.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-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, 14 Apr 2004 13:36:09 -0700 Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. The Last Call ends April 28. Yakov. ------- Forwarded Message Date: Wed, 14 Apr 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Route Reflection - An Alternative to Full Mesh IB GP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09174 for ; Wed, 14 Apr 2004 17:18: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 1BDreH-0000ps-50; Wed, 14 Apr 2004 17:10:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqu6-0003PV-BP for idr@optimus.ietf.org; Wed, 14 Apr 2004 16:22:38 -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 QAA22150 for ; Wed, 14 Apr 2004 16:22:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDqu4-0006rU-00 for idr@ietf.org; Wed, 14 Apr 2004 16:22:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDqt5-0006ks-00 for idr@ietf.org; Wed, 14 Apr 2004 16:21:36 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BDqsC-0006e8-00 for idr@ietf.org; Wed, 14 Apr 2004 16:20:40 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3EKK8l80756; Wed, 14 Apr 2004 13:20:08 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKK3J85908; Wed, 14 Apr 2004 13:20:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404142020.i3EKK3J85908@merlot.juniper.net> To: Alex Zinin cc: Stephen Kent , Steve Bellovin , saag@mit.edu, idr@ietf.org Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt In-Reply-To: Your message of "Fri, 02 Apr 2004 19:03:02 PST." <14514817.20040402190302@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39377.1081974003.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 14 Apr 2004 13:20:03 -0700 Alex, > Thanks for looking at this. My comments inline below. > > I've added the IDR mailing list, since your comments cover the base spec as > well. > > Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: > > Steve, > > > The text explaining why the MD5 checksum is not a good candidate for > > use in broader IETF protocol contexts is very well written. > > > The discussion of why BGP-4 can't easily change at this time to > > another integrity mechanism is also very good. However, when I looked > > quickly at the new BGP draft (intended to replace the extant RFC) I > > was unable to find any discussion of using the MD5 option. There are > > references to RFC 2385 in the discussion of what has changed, and in > > the security considerations section, and the normative references > > section. But a search on "MD5," "RFC 2385," "authentication," > > "integrity," or "security" does not point a reader to any text that > > says in any detail how to use this TCP option in the BGP context. > > As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP > Sessions via the TCP MD5 Signature Option", in turn, describes how the option > can be used to secure a TCP sessions, for BGP in particular. Is there somethi ng > specific you were looking for? > > > The > > section entitled "TCP Options that may be used with BGP" makes no > > reference to it. Can someone point me to where the new BGP document > > actually says how this TCP option is used? > > Appendix E "TCP options that may be used with BGP" could indeed mention that > the MD5 option can be used for BGP sessions. Yakov, please log this. Sure. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07578 for ; Wed, 14 Apr 2004 16:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqGB-00035s-SU; Wed, 14 Apr 2004 15:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq8w-0003sC-VM for idr@optimus.ietf.org; Wed, 14 Apr 2004 15:33:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18366; Wed, 14 Apr 2004 15:33:52 -0400 (EDT) Message-Id: <200404141933.PAA18366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: idr@ietf.org From: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2796bis-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, 14 Apr 2004 15:33:52 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Reflection - An Alternative to Full Mesh IBGP Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2796bis-00.txt Pages : 11 Date : 2004-4-14 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as 'Route Reflection' to alleviate the the need for 'full mesh' IBGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2796bis-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-rfc2796bis-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: <2004-4-14153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2796bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153513.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28868 for ; Wed, 14 Apr 2004 12:28: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 1BDnBG-0004uQ-4q; Wed, 14 Apr 2004 12:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm3Y-0000ed-8A for idr@optimus.ietf.org; Wed, 14 Apr 2004 11:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00287 for ; Wed, 14 Apr 2004 11:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDm3X-00016x-00 for idr@ietf.org; Wed, 14 Apr 2004 11:12:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDm2d-00013H-00 for idr@ietf.org; Wed, 14 Apr 2004 11:11:08 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BDm1v-0000y6-00 for idr@ietf.org; Wed, 14 Apr 2004 11:10:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3EF9qBm044247; Wed, 14 Apr 2004 08:09:52 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EF9qJ35243; Wed, 14 Apr 2004 08:09:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200404141509.i3EF9qJ35243@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88301.1081955392.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document 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, 14 Apr 2004 08:09:52 -0700 Folks, We receive a request to accept draft-lange-flexible-bgp-communities-02.txt as an IDR WG document. Please send comments to the list. The deadline for comments is April 28, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24534 for ; Mon, 12 Apr 2004 12:09: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 1BD3za-0006MR-In; Mon, 12 Apr 2004 12:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByHe-0006mN-UB for idr@optimus.ietf.org; Fri, 09 Apr 2004 11:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03555 for ; Fri, 9 Apr 2004 11:51:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByHd-0001gu-00 for idr@ietf.org; Fri, 09 Apr 2004 11:51:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByGB-0001ZP-00 for idr@ietf.org; Fri, 09 Apr 2004 11:49:40 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BByEy-0001Mk-00 for idr@ietf.org; Fri, 09 Apr 2004 11:48:24 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39Fll7X028058; Fri, 9 Apr 2004 11:47:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1653165747.20040408171556@psg.com> References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> <1653165747.20040408171556@psg.com> To: Alex Zinin From: Stephen Kent Cc: Steve Bellovin , saag@mit.edu, idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 9 Apr 2004 11:40:58 -0400 Alex, > > > >Steve, would you mind making a suggestion on how the text could be improved? >E.g., would a separate section in the main body of the document specifying >the requirement for TCP-MD5 support be useful? A reasonable approach would be to have a section of the document that describes the use of this TCP option. It should explain why/when one would use the option in the context of BGP links and what protection it offers. Somewhere there should be a discussion of precautions should be taken re selection and use of keys, but maybe this is more of a BCP matter than a protocol standards matter. > > >I didn't mean to argue whether the terminology is right or wrong, >I'll leave up >to you guys. My point was that we have to use the actual title of the document >when referring to it, even though the title may not accurately describe what's >inside. Anyway, Steve suggested that a clarifying note is put in the docs... actually, one often refers to an RFC by number in the text, and includes the title only in the references section. > > > But, in a more fundamental sense, we have already >> endorsed the inappropriate use of MD5 in routing protocols in terms >> of OSPF, and we're merely continuing the tradition with BGP and LDP >> :-). > >It seems a discussion on why MD5 is inappropriate or insufficient in >routing protocols would be interesting if we take it to RPSEC. > of course the issue is not MD5 per se, but the use of MD5 plus a secret bit string as a message authentication code, instead of HMAC, in any context. Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA11456 for ; Thu, 8 Apr 2004 21:01: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 1BBkOE-0000mS-GP; Thu, 08 Apr 2004 21:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkNk-0000ks-HX for idr@optimus.ietf.org; Thu, 08 Apr 2004 21:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17812 for ; Thu, 8 Apr 2004 21:00:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkNh-0007OB-00 for idr@ietf.org; Thu, 08 Apr 2004 21:00:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBk9g-0004kc-00 for idr@ietf.org; Thu, 08 Apr 2004 20:46:01 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjgd-0001vY-00 for idr@ietf.org; Thu, 08 Apr 2004 20:15:59 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjgb-000J8k-1f; Fri, 09 Apr 2004 00:15:57 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1653165747.20040408171556@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 17:15:56 -0700 Steve- [putting IDR back on the Cc: list--I'd like the WG to be in the loop] Wednesday, April 7, 2004, 8:09:53 AM, Stephen Kent wrote: > At 4:26 PM -0700 4/6/04, Alex Zinin wrote: >>Steve- >> >>> the BGP document cites mandatory use of RFC 2385 as one of the >>> changes, up front, but then never makes any reference to the RFC in >>> the text. That's not a good way to communicate the intent of the >>> change, i.e., the intent of the change has not been integrated into >>> the body of the spec. >> >>It seems that you simply have missed the following reference in the "Security >>Considerations" section: >> >> draft-ietf-idr-bgp4-23.txt: >> >> The authentication mechanism that an implementation of BGP MUST sup- >> port is specified in [RFC2385]. The authentication provided by this >> mechanism could be done on a per peer basis. >> >> BGP vulnerabilities analysis is discussed in [BGP_VULN]. > No, I didn't miss it, Alex. I consider it a trivial reference that > fails to do an adequate job. The Security Considerations section of a > document is not where one first specifies a requirement for a > protocol. It is a place to comment upon what has already been > specified, putting it in context relative to security. Steve, would you mind making a suggestion on how the text could be improved? E.g., would a separate section in the main body of the document specifying the requirement for TCP-MD5 support be useful? >> > in the context of Steve Bellovin's document there is no reason to >>> perpetuate the error of the RFC 2385 title, i.e., to continue to >>> refer to the message authentication code created by the use of a >>> shared secret and a hash function as a "signature." One might even >>> take this opportunity to point out that the title of the RFC is >>> misleading and should not be confused with digital signature >>> technologies. >> >>My understanding is that Steve used the wording from the 2385's title on >>purpose, since we're talking about a specific document with a specific title, >>plus about a TCP option with a specific name (though now considered >>misleading). > Alex, the terminology was always wrong, and I pointed that out to the > IESG when the RFC was out for last call years ago. But Jeff Schiller > apparently didn't think the terminology error was worth fixing, and I > doubt that the rest of the IESG was concerned back then. Don't phrase > this as though we're in the realm of revisionist political > correctness. It was wrong then, and it's still wrong. I didn't mean to argue whether the terminology is right or wrong, I'll leave up to you guys. My point was that we have to use the actual title of the document when referring to it, even though the title may not accurately describe what's inside. Anyway, Steve suggested that a clarifying note is put in the docs... >> >> >>> For contrast, RFC xxxx specifies use of MD5 in the same >>> fashion for OSPF security, but nobody is suggesting that this be >>> approved, presumably because there is no large, installed base, right? >> >>RFC 2328 includes the OSPF MD5 authentication option (similar to >>TCP-MD5 in its >>transport nature). It's widely deployed and is a full IETF Standard. >>If you mean >>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of >>only one or two implementations. > Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, > I was referring to 2238. We have a slightly odd situation here. > Steve's document explains why BGP is being progressed even though it > contains a normative reference to an RFC (TCP MD5 ...) that will not > be progressed. The argument is that the latter RFC is technically > poor, but it's not so awful to use it with BGP considering the > context, because it is widely deployed, and because it is the only > point-to-point authentication mechanism defined for BGP. Then there > is the minor mention of LDP at te end. > You suggest, above, that OSPF's use of MD5 is also widely deployed, > something of which I was not aware. (Or did you just mean that many > OSPF implementations support the feature, but you don't know if it is > tuend on?) All more-or-less mature OSPF implementations I know of certainly support the feature. As for deployment, OSPF MD5 _is_ being used in both SP and enterprise networks. I do not have numbers for you, but even as of 3-4 years ago (when I worked close with operators on a regular basis), it was not uncommon to see it configured. > OSPF does not use the TCP MD5 option, but rather uses MD5 > in the same marginal way internally. So, in one sense there is no > need to mention this in Steve's document, because it is just > explaining why the IESG is making an exception for BGP, and LDP in > the future. Agreed. > But, in a more fundamental sense, we have already > endorsed the inappropriate use of MD5 in routing protocols in terms > of OSPF, and we're merely continuing the tradition with BGP and LDP > :-). It seems a discussion on why MD5 is inappropriate or insufficient in routing protocols would be interesting if we take it to RPSEC. Thanks. Alex > >> > you are right that the primary focus of this discussion is >> > progression of BGP. But, since you argued that LDP is appropriately >> > included in the rationale discussion for this document, I assume you >> > will want to progress that RFC too, >> > otherwise why bother mentioning it now? I would rather not have to >> > revisit this at that time, so I suggest you ask the MPLS WG to make a >> > note of this error now. >> >>Looking at the LDP spec, it uses the word "signature" as part of the reference >>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued >>that 2385 uses incorrect terminology, it would be confusing to refer to it as >>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication >>Option", as this is not what 2385 specifies. > If you look at Steve's document, he uses the right terminology > throughout, while referring to the document via its RFC number. > That's a good model for any document that wants to avoid perpetuating > the terminology error inherent in the title of 2385. > Steve _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA11130 for ; Thu, 8 Apr 2004 20:52: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 1BBkFV-0008G0-KN; Thu, 08 Apr 2004 20:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkEu-0008EF-Mf for idr@optimus.ietf.org; Thu, 08 Apr 2004 20:51: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 UAA17246 for ; Thu, 8 Apr 2004 20:51:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkEr-0005h2-00 for idr@ietf.org; Thu, 08 Apr 2004 20:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBjsb-0002yp-00 for idr@ietf.org; Thu, 08 Apr 2004 20:28:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjJY-0006zW-00 for idr@ietf.org; Thu, 08 Apr 2004 19:52:08 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjJW-0006qH-4J; Thu, 08 Apr 2004 23:52:06 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1171876158.20040408165204@psg.com> To: idr@ietf.org CC: Stephen Kent , Steve Bellovin In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> <184815294.20040406162638@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 16:52:04 -0700 This is a forwarded message From: Stephen Kent To: Alex Zinin Cc: Steve Bellovin , saag@mit.edu Date: Wednesday, April 7, 2004, 8:09:53 AM Subject: [saag] draft-iesg-tcpmd5app-00.txt ===8<==============Original message text=============== At 4:26 PM -0700 4/6/04, Alex Zinin wrote: >Steve- > >> the BGP document cites mandatory use of RFC 2385 as one of the >> changes, up front, but then never makes any reference to the RFC in >> the text. That's not a good way to communicate the intent of the >> change, i.e., the intent of the change has not been integrated into >> the body of the spec. > >It seems that you simply have missed the following reference in the "Security >Considerations" section: > > draft-ietf-idr-bgp4-23.txt: > > The authentication mechanism that an implementation of BGP MUST sup- > port is specified in [RFC2385]. The authentication provided by this > mechanism could be done on a per peer basis. > > BGP vulnerabilities analysis is discussed in [BGP_VULN]. No, I didn't miss it, Alex. I consider it a trivial reference that fails to do an adequate job. The Security Considerations section of a document is not where one first specifies a requirement for a protocol. It is a place to comment upon what has already been specified, putting it in context relative to security. > > in the context of Steve Bellovin's document there is no reason to >> perpetuate the error of the RFC 2385 title, i.e., to continue to >> refer to the message authentication code created by the use of a >> shared secret and a hash function as a "signature." One might even >> take this opportunity to point out that the title of the RFC is >> misleading and should not be confused with digital signature >> technologies. > >My understanding is that Steve used the wording from the 2385's title on >purpose, since we're talking about a specific document with a specific title, >plus about a TCP option with a specific name (though now considered >misleading). Alex, the terminology was always wrong, and I pointed that out to the IESG when the RFC was out for last call years ago. But Jeff Schiller apparently didn't think the terminology error was worth fixing, and I doubt that the rest of the IESG was concerned back then. Don't phrase this as though we're in the realm of revisionist political correctness. It was wrong then, and it's still wrong. > > >> For contrast, RFC xxxx specifies use of MD5 in the same >> fashion for OSPF security, but nobody is suggesting that this be >> approved, presumably because there is no large, installed base, right? > >RFC 2328 includes the OSPF MD5 authentication option (similar to >TCP-MD5 in its >transport nature). It's widely deployed and is a full IETF Standard. >If you mean >"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of >only one or two implementations. Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, I was referring to 2238. We have a slightly odd situation here. Steve's document explains why BGP is being progressed even though it contains a normative reference to an RFC (TCP MD5 ...) that will not be progressed. The argument is that the latter RFC is technically poor, but it's not so awful to use it with BGP considering the context, because it is widely deployed, and because it is the only point-to-point authentication mechanism defined for BGP. Then there is the minor mention of LDP at te end. You suggest, above, that OSPF's use of MD5 is also widely deployed, something of which I was not aware. (Or did you just mean that many OSPF implementations support the feature, but you don't know if it is tuend on?) OSPF does not use the TCP MD5 option, but rather uses MD5 in the same marginal way internally. So, in one sense there is no need to mention this in Steve's document, because it is just explaining why the IESG is making an exception for BGP, and LDP in the future. But, in a more fundamental sense, we have already endorsed the inappropriate use of MD5 in routing protocols in terms of OSPF, and we're merely continuing the tradition with BGP and LDP :-). > > you are right that the primary focus of this discussion is > > progression of BGP. But, since you argued that LDP is appropriately > > included in the rationale discussion for this document, I assume you > > will want to progress that RFC too, > > otherwise why bother mentioning it now? I would rather not have to > > revisit this at that time, so I suggest you ask the MPLS WG to make a > > note of this error now. > >Looking at the LDP spec, it uses the word "signature" as part of the reference >to the "TCP MD5 Signature Option", specified in 2385. While it could be argued >that 2385 uses incorrect terminology, it would be confusing to refer to it as >something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication >Option", as this is not what 2385 specifies. If you look at Steve's document, he uses the right terminology throughout, while referring to the document via its RFC number. That's a good model for any document that wants to avoid perpetuating the terminology error inherent in the title of 2385. Steve ===8<===========End of original message text=========== _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA11131 for ; Thu, 8 Apr 2004 20:52: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 1BBkFW-0008G8-40; Thu, 08 Apr 2004 20:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkEw-0008EK-2n for idr@optimus.ietf.org; Thu, 08 Apr 2004 20:51:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17250 for ; Thu, 8 Apr 2004 20:51:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkEt-0005hQ-00 for idr@ietf.org; Thu, 08 Apr 2004 20:51:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBjsg-0002zx-00 for idr@ietf.org; Thu, 08 Apr 2004 20:28:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjJj-000722-00 for idr@ietf.org; Thu, 08 Apr 2004 19:52:19 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjJj-0006xe-L9; Thu, 08 Apr 2004 23:52:19 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5810329073.20040408165218@psg.com> To: idr@ietf.org CC: Stephen Kent , Steve Bellovin In-Reply-To: <20040407151311.9FA417B44@berkshire.research.att.com> References: Your message of "Wed, 07 Apr 2004 11:09:53 EDT." <20040407151311.9FA417B44@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-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: Thu, 8 Apr 2004 16:52:18 -0700 This is a forwarded message From: Steven M. Bellovin To: Stephen Kent Cc: Alex Zinin , saag@mit.edu Date: Wednesday, April 7, 2004, 8:13:10 AM Subject: [saag] draft-iesg-tcpmd5app-00.txt ===8<==============Original message text=============== In message , Stephen Kent writes: >If you look at Steve's document, he uses the right terminology >throughout, while referring to the document via its RFC number. >That's a good model for any document that wants to avoid perpetuating >the terminology error inherent in the title of 2385. > It's probably worth putting a note in my document noting the erroneous terminology in the title of 2385. It's not a bad idea having a similar parenthetical note in the bgp document. --Steve Bellovin, http://www.research.att.com/~smb ===8<===========End of original message text=========== _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06346 for ; Wed, 7 Apr 2004 11:06:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBEcA-0000Lr-T4; Wed, 07 Apr 2004 11:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAt4w-0003fE-28 for idr@optimus.ietf.org; Tue, 06 Apr 2004 12:05:34 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00946 for ; Tue, 6 Apr 2004 12:05:30 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAt4C-0003W6-Hp; Tue, 06 Apr 2004 12:04:48 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Idr] Last Call: 'BGP Extended Communities Attribute' to Proposed Standard 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, 06 Apr 2004 12:04:48 -0400 The IESG has received a request from the Inter-Domain Routing WG to consider the following document: - 'BGP Extended Communities Attribute ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-20. The implementation report can be found in the accompanying document: - 'BGP Extended Communities Attribute - Implementation Survey' The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities- 07.txt http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey- 02.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05078 for ; Wed, 7 Apr 2004 10:28:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBE25-0000VE-Ay; Wed, 07 Apr 2004 10: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 1BAWcD-0002uT-VY for idr@optimus.ietf.org; Mon, 05 Apr 2004 12:06:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10287 for ; Mon, 5 Apr 2004 12:06:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWcC-00048a-00 for idr@ietf.org; Mon, 05 Apr 2004 12:06:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWQ5-0002IS-00 for idr@ietf.org; Mon, 05 Apr 2004 11:53:57 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BAWEf-0000Am-00 for idr@ietf.org; Mon, 05 Apr 2004 11:42:05 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7Z015027; Mon, 5 Apr 2004 11:41:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <14514817.20040402190302@psg.com> References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> To: Alex Zinin From: Stephen Kent Cc: Steve Bellovin , saag@mit.edu, idr@ietf.org, Stephen Kent Content-Type: multipart/alternative; boundary="============_-1130942848==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 5 Apr 2004 09:49:49 -0400 --============_-1130942848==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:03 PM -0800 4/2/04, Alex Zinin wrote: >Steve- > >Thanks for looking at this. My comments inline below. > >I've added the IDR mailing list, since your comments cover the base spec as >well. > >Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: >> Steve, > >> The text explaining why the MD5 checksum is not a good candidate for >> use in broader IETF protocol contexts is very well written. > >> The discussion of why BGP-4 can't easily change at this time to >> another integrity mechanism is also very good. However, when I looked >> quickly at the new BGP draft (intended to replace the extant RFC) I >> was unable to find any discussion of using the MD5 option. There are >> references to RFC 2385 in the discussion of what has changed, and in >> the security considerations section, and the normative references >> section. But a search on "MD5," "RFC 2385," "authentication," >> "integrity," or "security" does not point a reader to any text that >> says in any detail how to use this TCP option in the BGP context. > >As you said, the spec refers to the RFC 2385. RFC 2385 titled >"Protection of BGP >Sessions via the TCP MD5 Signature Option", in turn, describes how the option >can be used to secure a TCP sessions, for BGP in particular. Is >there something >specific you were looking for? the BGP document cites mandatory use of RFC 2385 as one of the changes, up front, but then never makes any reference to the RFC in the text. That's not a good way to communicate the intent of the change, i.e., the intent of the change has not been integrated into the body of the spec. in the context of Steve Bellovin's document there is no reason to perpetuate the error of the RFC 2385 title, i.e., to continue to refer to the message authentication code created by the use of a shared secret and a hash function as a "signature." One might even take this opportunity to point out that the title of the RFC is misleading and should not be confused with digital signature technologies. > > The >> section entitled "TCP Options that may be used with BGP" makes no >> reference to it. Can someone point me to where the new BGP document >> actually says how this TCP option is used? > >Appendix E "TCP options that may be used with BGP" could indeed >mention that the >MD5 option can be used for BGP sessions. Yakov, please log this. > >> Also, I note that the document abstract says: > >> "Routing information exchanged via BGP supports only the destination- >> based forwarding paradigm, which assumes that a router forwards a >> packet based solely on the destination address carried in the IP >> header of the packet. This, in turn, reflects the set of policy >> decisions that can (and can not) be enforced using BGP. BGP can >> support only the policies conforming to the destination-based >> forwarding paradigm." > >> The term "solely" seems inappropriate, since it ignores the role that >> local policy plays in route selection, right? I think I know what the >> authors meant to say, but the text does not seem to be correct in >> this regard. > >It seems that the abstract is correct, actually. Routers indeed _forward_ >packets using solely the destination address from the packet, as opposed to >using say destination and source address, or even more granular forwarding >decisions. Policies are taken into consideration when the RIB and FIB are >constructed, which is not part of forwarding. Good point. > > LDP is a much newer protocol and so there is less of a "large >> installed base that has been using this for years" sense. > >We do have quite considerable installed base for LDP and strictly speaking it >has been there for a few years. So, though the statement may not >sound as strong >when applied to LDP, it is correct. then the text should say that LDP represents as big an installed base as BGP's use of MD5, if that is the case. If not, then find some accurate but similarly persuasive characterization that justifies this use. For contrast, RFC xxxx specifies use of MD5 in the same fashion for OSPF security, but nobody is suggesting that this be approved, presumably because there is no large, installed base, right? > >> I am also >> disturbed that the LDP spec (RFC 3036) refers to this as a signature >> as well, and incorporates bad text from the old BGP RFC, e.g., "... >> acts like a signature for that segment .." further perpetuating the >> confusion between message authentication codes and digital >> signatures. Any chance we can get this fixed in both the BGP document >> before it progresses and in the next rev of 3036? > >The BGP spec (neither old nor new) does not include this >terminology, so I don't >think we need to fix it from this perspective. > >Improvement of the LDP spec could be considered by the MPLS WG when it starts >working on a new revision of the spec. > >Thank you. > >Alex you are right that the primary focus of this discussion is progression of BGP. But, since you argued that LDP is appropriately included in the rationale discussion for this document, I assume you will want to progress that RFC too, otherwise why bother mentioning it now? I would rather not have to revisit this at that time, so I suggest you ask the MPLS WG to make a note of this error now. Steve --============_-1130942848==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] draft-iesg-tcpmd5app-00.txt
At 7:03 PM -0800 4/2/04, Alex Zinin wrote:
Steve-

Thanks for looking at this. My comments inline below.

I've added the IDR mailing list, since your comments cover the base spec as
well.

Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> Steve,

> The text explaining why the MD5 checksum is not a good candidate for
> use in broader IETF protocol contexts is very well written.

> The discussion of why BGP-4 can't easily change at this time to
> another integrity mechanism is also very good. However, when I looked
> quickly at the new BGP draft (intended to replace the extant RFC) I
> was unable to find any discussion of using the MD5 option. There are
> references to RFC 2385 in the discussion of what has changed, and in
> the security considerations section, and the normative references
> section. But a search on "MD5," "RFC 2385," "authentication,"
> "integrity," or "security" does not point a reader to any text that
> says in any detail how to use this TCP option in the BGP context.

As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP
Sessions via the TCP MD5 Signature Option", in turn, describes how the option
can be used to secure a TCP sessions, for BGP in particular. Is there something
specific you were looking for?

the BGP document cites mandatory use of RFC 2385 as one of the changes, up front, but then never makes any reference to the RFC in the text. That's not a good way to communicate the intent of the change, i.e., the intent of the change has not been integrated into the body of the spec.

in the context of Steve Bellovin's document there is no reason to perpetuate the error of the RFC 2385 title, i.e., to continue to refer to the message authentication code created by the use of a shared secret and a hash function as a "signature."  One might even take this opportunity to point out that the title of the RFC is misleading and should not be confused with digital signature technologies.

> The
> section entitled "TCP Options that may be used with BGP" makes no
> reference to it. Can someone point me to where the new BGP document
> actually says how this TCP option is used?

Appendix E "TCP options that may be used with BGP" could indeed mention that the
MD5 option can be used for BGP sessions. Yakov, please log this.

> Also, I note that the document abstract says:

> "Routing information exchanged via BGP supports only the destination-
>     based forwarding paradigm, which assumes that a router forwards a
>     packet based solely on the destination address carried in the IP
>     header of the packet. This, in turn, reflects the set of policy
>     decisions that can (and can not) be enforced using BGP. BGP can
>     support only the policies conforming to the destination-based
>     forwarding paradigm."

> The term "solely" seems inappropriate, since it ignores the role that
> local policy plays in route selection, right? I think I know what the
> authors meant to say, but the text does not seem to be correct in
> this regard.

It seems that the abstract is correct, actually. Routers indeed _forward_
packets using solely the destination address from the packet, as opposed to
using say destination and source address, or even more granular forwarding
decisions. Policies are taken into consideration when the RIB and FIB are
constructed, which is not part of forwarding.

Good point.

> LDP is a much newer protocol and so there is less of a "large
> installed base that has been using this for years" sense.

We do have quite considerable installed base for LDP and strictly speaking it
has been there for a few years. So, though the statement may not sound as strong
when applied to LDP, it is correct.

then the text should say that LDP represents as big an installed base as BGP's use of MD5, if that is the case. If not, then find some accurate but similarly persuasive characterization that justifies this use. For contrast, RFC xxxx specifies use of MD5 in the same fashion for OSPF security, but nobody is suggesting that this be approved, presumably because there is no large, installed base, right?


>  I am also
> disturbed that the LDP spec (RFC 3036) refers to this as a signature
> as well, and incorporates bad text from the old BGP RFC, e.g., "...
> acts like a signature for that segment .." further perpetuating the
> confusion between message authentication codes and digital
> signatures. Any chance we can get this fixed in both the BGP document
> before it progresses and in the next rev of 3036?

The BGP spec (neither old nor new) does not include this terminology, so I don't
think we need to fix it from this perspective.

Improvement of the LDP spec could be considered by the MPLS WG when it starts
working on a new revision of the spec.

Thank you.

Alex

you are right that the primary focus of this discussion is progression of BGP. But, since you argued that LDP is appropriately included in the rationale discussion for this document, I assume you will want to progress that RFC too,
otherwise why bother mentioning it now?  I would rather not have to revisit this at that time, so I suggest you ask the MPLS WG to make a note of this error now.

Steve
--============_-1130942848==_ma============-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05077 for ; Wed, 7 Apr 2004 10:28: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 1BBE24-0000V4-Pr; Wed, 07 Apr 2004 10:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bcV-0005bo-JR for idr@optimus.ietf.org; Thu, 25 Mar 2004 15:38:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19416; Thu, 25 Mar 2004 15:38:28 -0500 (EST) Message-Id: <200403252038.PAA19416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-cease-subcode-05.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: Thu, 25 Mar 2004 15:38:28 -0500 --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-05.txt Pages : 5 Date : 2004-3-25 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-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-cease-subcode-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-cease-subcode-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: <2004-3-25154613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-25154613.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA21470 for ; Tue, 6 Apr 2004 21:19: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 1BB1iX-0008Eg-In; Tue, 06 Apr 2004 21:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1hb-0007ya-Aj for idr@optimus.ietf.org; Tue, 06 Apr 2004 21:18:03 -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 VAA19410 for ; Tue, 6 Apr 2004 21:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1hY-0007F5-00 for idr@ietf.org; Tue, 06 Apr 2004 21:18:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0cZ-0000rf-00 for idr@ietf.org; Tue, 06 Apr 2004 20:08:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAzxq-00027v-00 for idr@ietf.org; Tue, 06 Apr 2004 19:26:43 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAzxo-0005Vo-8j; Tue, 06 Apr 2004 23:26:40 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <184815294.20040406162638@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> <14514817.20040402190302@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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: Tue, 6 Apr 2004 16:26:38 -0700 Steve- > the BGP document cites mandatory use of RFC 2385 as one of the > changes, up front, but then never makes any reference to the RFC in > the text. That's not a good way to communicate the intent of the > change, i.e., the intent of the change has not been integrated into > the body of the spec. It seems that you simply have missed the following reference in the "Security Considerations" section: draft-ietf-idr-bgp4-23.txt: The authentication mechanism that an implementation of BGP MUST sup- port is specified in [RFC2385]. The authentication provided by this mechanism could be done on a per peer basis. BGP vulnerabilities analysis is discussed in [BGP_VULN]. > in the context of Steve Bellovin's document there is no reason to > perpetuate the error of the RFC 2385 title, i.e., to continue to > refer to the message authentication code created by the use of a > shared secret and a hash function as a "signature." One might even > take this opportunity to point out that the title of the RFC is > misleading and should not be confused with digital signature > technologies. My understanding is that Steve used the wording from the 2385's title on purpose, since we're talking about a specific document with a specific title, plus about a TCP option with a specific name (though now considered misleading). >> > LDP is a much newer protocol and so there is less of a "large >>> installed base that has been using this for years" sense. >> >>We do have quite considerable installed base for LDP and strictly speaking it >>has been there for a few years. So, though the statement may not >>sound as strong >>when applied to LDP, it is correct. > then the text should say that LDP represents as big an installed base > as BGP's use of MD5, if that is the case. If not, then find some > accurate but similarly persuasive characterization that justifies > this use. OK. We'll see if the wording can be improved. > For contrast, RFC xxxx specifies use of MD5 in the same > fashion for OSPF security, but nobody is suggesting that this be > approved, presumably because there is no large, installed base, right? RFC 2328 includes the OSPF MD5 authentication option (similar to TCP-MD5 in its transport nature). It's widely deployed and is a full IETF Standard. If you mean "OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of only one or two implementations. >>> I am also >>> disturbed that the LDP spec (RFC 3036) refers to this as a signature >>> as well, and incorporates bad text from the old BGP RFC, e.g., "... >>> acts like a signature for that segment .." further perpetuating the >>> confusion between message authentication codes and digital >>> signatures. Any chance we can get this fixed in both the BGP document >>> before it progresses and in the next rev of 3036? >> >>The BGP spec (neither old nor new) does not include this >>terminology, so I don't >>think we need to fix it from this perspective. >> >>Improvement of the LDP spec could be considered by the MPLS WG when it starts >>working on a new revision of the spec. >> >>Thank you. >> >>Alex > you are right that the primary focus of this discussion is > progression of BGP. But, since you argued that LDP is appropriately > included in the rationale discussion for this document, I assume you > will want to progress that RFC too, > otherwise why bother mentioning it now? I would rather not have to > revisit this at that time, so I suggest you ask the MPLS WG to make a > note of this error now. Looking at the LDP spec, it uses the word "signature" as part of the reference to the "TCP MD5 Signature Option", specified in 2385. While it could be argued that 2385 uses incorrect terminology, it would be confusing to refer to it as something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication Option", as this is not what 2385 specifies. Thanks Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA24337 for ; Fri, 2 Apr 2004 22:05:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bSv-0002Wk-A2; Fri, 02 Apr 2004 22:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bSL-0002SU-Ny for idr@optimus.ietf.org; Fri, 02 Apr 2004 22:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20382 for ; Fri, 2 Apr 2004 22:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bSI-0006xZ-00 for idr@ietf.org; Fri, 02 Apr 2004 22:04:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bRU-0006r6-00 for idr@ietf.org; Fri, 02 Apr 2004 22:03:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9bR3-0006k0-00 for idr@ietf.org; Fri, 02 Apr 2004 22:03:05 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9bR2-000LIY-CX; Sat, 03 Apr 2004 03:03:04 +0000 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14514817.20040402190302@psg.com> To: Stephen Kent CC: Steve Bellovin , saag@mit.edu, idr@ietf.org In-Reply-To: References: <20040331191330.4BE787B44@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-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, 2 Apr 2004 19:03:02 -0800 Steve- Thanks for looking at this. My comments inline below. I've added the IDR mailing list, since your comments cover the base spec as well. Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote: > Steve, > The text explaining why the MD5 checksum is not a good candidate for > use in broader IETF protocol contexts is very well written. > The discussion of why BGP-4 can't easily change at this time to > another integrity mechanism is also very good. However, when I looked > quickly at the new BGP draft (intended to replace the extant RFC) I > was unable to find any discussion of using the MD5 option. There are > references to RFC 2385 in the discussion of what has changed, and in > the security considerations section, and the normative references > section. But a search on "MD5," "RFC 2385," "authentication," > "integrity," or "security" does not point a reader to any text that > says in any detail how to use this TCP option in the BGP context. As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP Sessions via the TCP MD5 Signature Option", in turn, describes how the option can be used to secure a TCP sessions, for BGP in particular. Is there something specific you were looking for? > The > section entitled "TCP Options that may be used with BGP" makes no > reference to it. Can someone point me to where the new BGP document > actually says how this TCP option is used? Appendix E "TCP options that may be used with BGP" could indeed mention that the MD5 option can be used for BGP sessions. Yakov, please log this. > Also, I note that the document abstract says: > "Routing information exchanged via BGP supports only the destination- > based forwarding paradigm, which assumes that a router forwards a > packet based solely on the destination address carried in the IP > header of the packet. This, in turn, reflects the set of policy > decisions that can (and can not) be enforced using BGP. BGP can > support only the policies conforming to the destination-based > forwarding paradigm." > The term "solely" seems inappropriate, since it ignores the role that > local policy plays in route selection, right? I think I know what the > authors meant to say, but the text does not seem to be correct in > this regard. It seems that the abstract is correct, actually. Routers indeed _forward_ packets using solely the destination address from the packet, as opposed to using say destination and source address, or even more granular forwarding decisions. Policies are taken into consideration when the RIB and FIB are constructed, which is not part of forwarding. > LDP is a much newer protocol and so there is less of a "large > installed base that has been using this for years" sense. We do have quite considerable installed base for LDP and strictly speaking it has been there for a few years. So, though the statement may not sound as strong when applied to LDP, it is correct. > I am also > disturbed that the LDP spec (RFC 3036) refers to this as a signature > as well, and incorporates bad text from the old BGP RFC, e.g., "... > acts like a signature for that segment .." further perpetuating the > confusion between message authentication codes and digital > signatures. Any chance we can get this fixed in both the BGP document > before it progresses and in the next rev of 3036? The BGP spec (neither old nor new) does not include this terminology, so I don't think we need to fix it from this perspective. Improvement of the LDP spec could be considered by the MPLS WG when it starts working on a new revision of the spec. Thank you. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20860 for ; Fri, 2 Apr 2004 14:50:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S0V-0005l4-3x; Fri, 02 Apr 2004 11:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9PgA-00022V-5w for idr@optimus.ietf.org; Fri, 02 Apr 2004 09:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10540 for ; Fri, 2 Apr 2004 09:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Pg8-0006l1-00 for idr@ietf.org; Fri, 02 Apr 2004 09:29:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Pf9-0006fB-00 for idr@ietf.org; Fri, 02 Apr 2004 09:28:52 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B9PeB-0006Tu-00; Fri, 02 Apr 2004 09:27:51 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i32ERKl96082; Fri, 2 Apr 2004 06:27:20 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i32EREJ30570; Fri, 2 Apr 2004 06:27:14 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200404021427.i32EREJ30570@merlot.juniper.net> To: Alex Zinin , Bill Fenner cc: idr@ietf.org, iesg-secretary@ietf.org, skh@nexthop.com, yakov@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9681.1080916034.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] BGP Extended Communities to Proposed Standard 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, 02 Apr 2004 06:27:14 -0800 Alex and Bill, The IDR WG would like to ask the IESG to advance BGP Extended Communities to a Proposed Standard. The spec is draft-ietf-idr-bgp-ext-communities-07.txt. The implementation report is draft-rekhter-ext-communities-survey-02.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr