Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA05056 for ; Sun, 29 Feb 2004 23:45:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfIc-0000bH-3g; Sun, 29 Feb 2004 23:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfI7-0000aD-RM for idr@optimus.ietf.org; Sun, 29 Feb 2004 23:44:31 -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 XAA01716 for ; Sun, 29 Feb 2004 23:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfI5-0005b4-00 for idr@ietf.org; Sun, 29 Feb 2004 23:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfHD-0005UW-00 for idr@ietf.org; Sun, 29 Feb 2004 23:43:36 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfGW-0005Lv-00 for idr@ietf.org; Sun, 29 Feb 2004 23:42:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i214gNm28160 for ; Mon, 1 Mar 2004 06:42:23 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) 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: Mon, 1 Mar 2004 06:42:23 +0200 (EET) FWIW, I do ot believe my re-opening this issue -- has been addressed. In short, there are very valid operational requirements why BGP should consider route of any protocol, not just BGP, as active. (This is the problem with point-to-point and loopback addresses.) I can also raise this issue at IETF LC, or later at IESG review time, of course. My first message below. ==== Date: Tue, 7 Oct 2003 22:56:30 +0300 (EEST) From: Pekka Savola To: Yakov Rekhter Cc: idr@ietf.org Subject: issue 11.2: active route, again [Re: comments on idr-bgp4-20] Hi again, [clipping the quote down] On Tue, 30 Sep 2003, Yakov Rekhter wrote: [...] > From draft-ietf-idr-bgp-issues-01.txt: > > After some additional discussion (in the "issue 11.2" thread), we > have come to a consensus on this text: > > In the context of this document we assume that a BGP speaker > advertises to its peers only those routes that it itself uses (in > this context a BGP speaker is said to "use" a BGP route if it is the > most preferred BGP route and is used in forwarding). All other cases > are outside the scope of this document. > > This issue is at consensus. > > So, the text in the spec represents consensus of the WG. Also note > the last sentence in the above paragraph. I've looked at the several threads in the archives, which do not seem to address the relevant points at all. So, I think the issue needs to be reconsidered. For example, consider a scenario of three routers in two ASs: rtr1 | | rtr2 --- rtr3 AS1 | ---- | AS2 AS2 -----' '----- rtr3 is configured to advertise prefix 1.0.0.0/8 using BGP. It has an IBGP session to rtr2, where it will advertise it. The AS2 also has an IGP, which includes only the loopbacks and point-to-point addresses of the AS. IBGP also includes the loopback addresses and point-to-point addresses. AS2 also wants to advertise the loopback addresses and PtP's to AS1 using specific communities marked at the routers. (There are multiple reasons advertising loopbacks/ptps such is desirable.. for example, our network employs private AS numbers and eBGP sessions and this is vital.) Now, rtr2 advertises the prefix 1.0.0.0/8 just fine using eBGP to rtr1, but the loopback addresses and PtP's won't get advertised because the IGP is more preferred, and for BGP's perspective, the BGP routes are not "active". Workarounds to this issue exist: - use an implementation-specific clause like "advertise-inactive", breaking the spec, to advertise them anyway, or - redistribute the IGP routes to BGP at the border router rtr2, losing communities etc. markings of iBGP in the process. Ugly. What I'm arguing here that there seem to be very clear operational reasons why the "BGP route must be used for forwarding" is very counterproductive and we should fix/clarify the spec to have a more useful definition for it. Are there any killer arguments why this is *NOT* a good idea? ====== ---------- Forwarded message ---------- Date: Thu, 9 Oct 2003 19:36:49 +0300 (EEST) From: Pekka Savola To: Pedro Roque Marques Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] On Wed, 8 Oct 2003, Pedro Roque Marques wrote: > Pekka Savola writes: > > On Tue, 7 Oct 2003, Pedro Roque Marques wrote: > >> Pekka Savola writes: > Are there any killer arguments why this is > >> *NOT* a good idea? > >> > >> The main objective of BGP is to make sure that there are no routing > >> or forwarding loops. When BGP advertises a route that is not in the > >> forwarding table those guarantees disapear. > > > The route to the same prefix (and in this case, the same nexthop as > > well) _is_ in the forwarding table. > > - BGP shouldn't be required to understand which next-hops other > protocols use. Who said it would have to? All it has to do it to look at the forwarding table, which it must be able to do anyway. > - Given that it typically doesn, and actually typically a route w/ > another protocol as a different next-hop, there is no way to guarantee > that you will not have routing/forwarding loops. I think the practice has shown this does not occur. -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA04829 for ; Sun, 29 Feb 2004 23:19:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxetR-000686-S8; Sun, 29 Feb 2004 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axesr-0005za-DD for idr@optimus.ietf.org; Sun, 29 Feb 2004 23:18:25 -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 XAA00096 for ; Sun, 29 Feb 2004 23:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axesp-0002zL-00 for idr@ietf.org; Sun, 29 Feb 2004 23:18:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axert-0002tS-00 for idr@ietf.org; Sun, 29 Feb 2004 23:17:26 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Axer4-0002om-00 for idr@ietf.org; Sun, 29 Feb 2004 23:16:34 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axer4-000Dma-Gb; Mon, 01 Mar 2004 04:16:34 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9120194908.20040301131614@psg.com> To: "Susan Hares" CC: idr@ietf.org Subject: Re: [Idr] FW: Here's the bundle for BGP to go to the IESG In-Reply-To: References: 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.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO 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, 1 Mar 2004 13:16:14 +0900 For information, the following two documents are not in the IETF draft repository-- > 6) BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt > 7) BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt --we'll have to wait until they are available before we can put them in the bundle and start the IETF LC on the whole group. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA04222 for ; Sun, 29 Feb 2004 21:58:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdd3-0008EZ-50; Sun, 29 Feb 2004 21:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdcN-0008Df-Ez for idr@optimus.ietf.org; Sun, 29 Feb 2004 21:57:19 -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 VAA26750 for ; Sun, 29 Feb 2004 21:57:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdcK-0003EA-00 for idr@ietf.org; Sun, 29 Feb 2004 21:57:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdbN-00039r-00 for idr@ietf.org; Sun, 29 Feb 2004 21:56:17 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxdaW-00031A-00 for idr@ietf.org; Sun, 29 Feb 2004 21:55:24 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D84C02D48EF for ; Sun, 29 Feb 2004 21:54:54 -0500 (EST) 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 18290-01-2 for ; Sun, 29 Feb 2004 21:54:53 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F0F942D48E5 for ; Sun, 29 Feb 2004 21:54:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Reminder Thread-Index: AcP/OJI874W/3PUMT2S08i86aLrJtA== From: "Susan Hares" To: 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] Reminder Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 29 Feb 2004 21:54:53 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA04222 IDR agenda is **not** posted on the ietf web site. Please refer to the following web site: www.ndzh.com/idr It has today's agenda. Follow along or ask questions. If you want to reach me directly on IM - try suehares on AOL during the meeting. Sue _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA03919 for ; Sun, 29 Feb 2004 21:23:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd5B-0004tl-SP; Sun, 29 Feb 2004 21:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd4X-0004sO-UK for idr@optimus.ietf.org; Sun, 29 Feb 2004 21:22:21 -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 VAA24575 for ; Sun, 29 Feb 2004 21:22:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd4V-000720-00 for idr@ietf.org; Sun, 29 Feb 2004 21:22:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd3a-0006x9-00 for idr@ietf.org; Sun, 29 Feb 2004 21:21:23 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Axd2y-0006qp-00 for idr@ietf.org; Sun, 29 Feb 2004 21:20:44 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF25E2D4826 for ; Sun, 29 Feb 2004 21:20:14 -0500 (EST) 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 17641-02-8 for ; Sun, 29 Feb 2004 21:20:13 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E68492D4823 for ; Sun, 29 Feb 2004 21:20:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Chat on IDR charter Thread-Index: AcP/IJM1qPO3yS5UTrS6gBYXjxzO4QAEChfAAAB8RqA= From: "Susan Hares" To: 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] FW: Here's the bundle for BGP to go to the IESG Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 29 Feb 2004 21:20:13 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA03919 At last: We've submitted the following bundle of IDR drafts to the IESG, and are looking forward to taking new charter items. Sue and Yakov -----Original Message----- From: Susan Hares Sent: Sunday, February 29, 2004 9:01 PM To: 'Alex Zinin'; Yakov Rekhter Cc: Bill Fenner Subject: Here's the bundle for BGP to go to the IESG Alex: The following drafts are a part of the bundle that needs to go forward: 1) BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt 2) BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt 3) BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt 4) BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt 5) Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt 6) BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt 7) BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA24893 for ; Sun, 29 Feb 2004 01:24:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKMr-0001Uv-7q; Sun, 29 Feb 2004 01:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKMW-0001Q4-MK for idr@optimus.ietf.org; Sun, 29 Feb 2004 01:23:40 -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 BAA24606 for ; Sun, 29 Feb 2004 01:23:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKMT-0001Zs-00 for idr@ietf.org; Sun, 29 Feb 2004 01:23:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxKLW-0001Vc-00 for idr@ietf.org; Sun, 29 Feb 2004 01:22:39 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKKj-0001Mx-00 for idr@ietf.org; Sun, 29 Feb 2004 01:21:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T6LKx13889 for ; Sun, 29 Feb 2004 08:21:20 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 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: Sun, 29 Feb 2004 08:21:20 +0200 (EET) After some off-list iteration, a revamped version of the possible text could be: In certain common deployment scenarios, the next-hop addresses are supposed to be valid only if resolved via routes of a specific type (e.g., IGP, connected or local). There are likely less specific routes from other sources (e.g., static or BGP) which may resolve the next-hops as well, but such resolvability typically leads to problems when the less specific route actually can't be used to reach the next-hop, and the BGP routes are not invalidated even though their next-hop is, for all intents and purposes, unroutable. Therefore, it is advisable that the implementations allow the operator to specify which routes should yield a positive result if they covered the the next-hop. .. thoughts? This doesn't have any MAY/SHOULD etc. terminology, at least yet -- maybe it should. -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA24454 for ; Sun, 29 Feb 2004 00:34:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJaU-0005EE-R3; Sun, 29 Feb 2004 00:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJaR-0005DD-L3 for idr@optimus.ietf.org; Sun, 29 Feb 2004 00:33:59 -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 AAA23120 for ; Sun, 29 Feb 2004 00:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJaP-00054l-00 for idr@ietf.org; Sun, 29 Feb 2004 00:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJZW-0004xR-00 for idr@ietf.org; Sun, 29 Feb 2004 00:33:03 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJYo-0004mR-00 for idr@ietf.org; Sun, 29 Feb 2004 00:32:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T5VX413141; Sun, 29 Feb 2004 07:31:33 +0200 From: Pekka Savola To: curtis@fictitious.org cc: "John G. Scudder" , Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 In-Reply-To: <200402281805.i1SI5cRX049251@workhorse.fictitious.org> 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: Sun, 29 Feb 2004 07:31:33 +0200 (EET) On Sat, 28 Feb 2004, Curtis Villamizar wrote: > If the next hop is covered by a discard route it is considered > unresolvable. I'm not sure I understand why this is a problem. No; it's still "resolvable" -- and that's the exact problem here. > Is there something I'm missing? Is there actually a legitimate reason > that you would install a discard route that covered either your BGP > peer's address or some address that your BGP peer would decide to use > as a next hop? Do people normally install discard routes covering > their IBGP peer's addresses? [That last one was a bit of a rhetorical > question]. Discard aggregates, yes -- for example, to originate BGP default routes, or to originate a superblock of your addresses. -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA23394 for ; Sat, 28 Feb 2004 22:03: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 1AxHEN-0003tR-Bw; Sat, 28 Feb 2004 22:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEop-0002HG-Kz for idr@optimus.ietf.org; Sat, 28 Feb 2004 19:28:31 -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 TAA12306 for ; Sat, 28 Feb 2004 19:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEon-00062T-00 for idr@ietf.org; Sat, 28 Feb 2004 19:28:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnP-0005lF-00 for idr@ietf.org; Sat, 28 Feb 2004 19:27:04 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmc-0005ao-00 for idr@ietf.org; Sat, 28 Feb 2004 19:26:14 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1T0PHRX051311; Sat, 28 Feb 2004 19:25:17 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402290025.i1T0PHRX051311@workhorse.fictitious.org> To: Yakov Rekhter cc: curtis@fictitious.org, Pedro Roque Marques , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Sat, 28 Feb 2004 16:09:24 PST." <200402290009.i1T09Oo29392@merlot.juniper.net> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Sat, 28 Feb 2004 19:25:17 -0500 In message <200402290009.i1T09Oo29392@merlot.juniper.net>, Yakov Rekhter writes : > Curtis, > > [clipped...] > > > Pedro, > > > > If you have separate timers for route origination/advertisement and > > up/down and the best solution is to set them all the same then it is > > possible to set them all the same. > > > > If you specify that they must be the same and that doesn't turn out to > > be the best way to do things you are stuck. > > > > Its clear that there isn't agreement on the best solution, so for the > > time being flexibility is needed. > > One point to keep in mind is that since we are moving the spec to > a Draft Standard, a *necessary* condition for relaxing the spec to > support the flexibility you mentioned above would be more than > one implementation that supports such flexibility. > > Yakov. Maybe not if it is a SHOULD and we are acknoledging the work in Signcomm that indicates that slow propogation of withdraw is bad. Existing implementations are conforming and there are no interoperability problems with a timer that can be set to more than one value. I understand that you don't want to change the spec. Again. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA23393 for ; Sat, 28 Feb 2004 22:03: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 1AxHEO-0003tZ-3j; Sat, 28 Feb 2004 22:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFXK-0004zl-K4 for idr@optimus.ietf.org; Sat, 28 Feb 2004 20:14:30 -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 UAA13994 for ; Sat, 28 Feb 2004 20:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFXI-000374-00 for idr@ietf.org; Sat, 28 Feb 2004 20:14:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFWO-00031V-00 for idr@ietf.org; Sat, 28 Feb 2004 20:13:33 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxFVU-0002vy-00 for idr@ietf.org; Sat, 28 Feb 2004 20:12:36 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1T1BjRX051484; Sat, 28 Feb 2004 20:11:45 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402290111.i1T1BjRX051484@workhorse.fictitious.org> To: Yakov Rekhter cc: curtis@fictitious.org, Pedro Roque Marques , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Sat, 28 Feb 2004 16:34:42 PST." <200402290034.i1T0Ygo30433@merlot.juniper.net> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Sat, 28 Feb 2004 20:11:45 -0500 In message <200402290034.i1T0Ygo30433@merlot.juniper.net>, Yakov Rekhter writes : > Curtis, > > > > [clipped...] > > > > > > > Pedro, > > > > > > > > If you have separate timers for route origination/advertisement and > > > > up/down and the best solution is to set them all the same then it is > > > > possible to set them all the same. > > > > > > > > If you specify that they must be the same and that doesn't turn out to > > > > be the best way to do things you are stuck. > > > > > > > > Its clear that there isn't agreement on the best solution, so for the > > > > time being flexibility is needed. > > > > > > One point to keep in mind is that since we are moving the spec to > > > a Draft Standard, a *necessary* condition for relaxing the spec to > > > support the flexibility you mentioned above would be more than > > > one implementation that supports such flexibility. > > > > > > Yakov. > > > > > > Maybe not if it is a SHOULD and we are acknoledging the work in > > Signcomm that indicates that slow propogation of withdraw is bad. > > Existing implementations are conforming and there are no > > interoperability problems with a timer that can be set to more than > > one value. > > rfc1264 is quite clear on this topic: > > 4) There must be evidence that all features of the protocol have > been tested, running between at least two implementations. > > Note that the above quote does not distinguish between SHOULD > and MUST features. > > > I understand that you don't want to change the spec. Again. > > I have no problem with changing the spec, as long as the change > reflects what is implemented and deployed. > > Yakov. Yakov, The NSS gated BGP at least at one time had a shorter withdraw than advertise timer. Both were configurable - all you had to do is recompile. :-) If you have an NSS in your basement we could try to prove interoperability. If you need some spaes, I have some RS960 cards or maybe Mark Knopper can dig one up (literally). Or we could ask the Smithsonian if we could borrow theirs for interoperability testing of a particular feature. :-) Or maybe we could leave the spec as is. Tough call. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA22591 for ; Sat, 28 Feb 2004 20:24:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgj-0005dP-4d; Sat, 28 Feb 2004 20:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEwd-0002YY-3I for idr@optimus.ietf.org; Sat, 28 Feb 2004 19:36:35 -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 TAA12719 for ; Sat, 28 Feb 2004 19:36:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEwb-0006tW-00 for idr@ietf.org; Sat, 28 Feb 2004 19:36:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEvi-0006oI-00 for idr@ietf.org; Sat, 28 Feb 2004 19:35:39 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AxEvP-0006hW-00 for idr@ietf.org; Sat, 28 Feb 2004 19:35:19 -0500 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 i1T0YgBm011158; Sat, 28 Feb 2004 16:34:42 -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 i1T0Ygo30433; Sat, 28 Feb 2004 16:34:42 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402290034.i1T0Ygo30433@merlot.juniper.net> To: curtis@fictitious.org cc: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: Your message of "Sat, 28 Feb 2004 19:25:17 EST." <200402290025.i1T0PHRX051311@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63472.1078014882.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=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: Sat, 28 Feb 2004 16:34:42 -0800 Curtis, > > [clipped...] > > > > > Pedro, > > > > > > If you have separate timers for route origination/advertisement and > > > up/down and the best solution is to set them all the same then it is > > > possible to set them all the same. > > > > > > If you specify that they must be the same and that doesn't turn out to > > > be the best way to do things you are stuck. > > > > > > Its clear that there isn't agreement on the best solution, so for the > > > time being flexibility is needed. > > > > One point to keep in mind is that since we are moving the spec to > > a Draft Standard, a *necessary* condition for relaxing the spec to > > support the flexibility you mentioned above would be more than > > one implementation that supports such flexibility. > > > > Yakov. > > > Maybe not if it is a SHOULD and we are acknoledging the work in > Signcomm that indicates that slow propogation of withdraw is bad. > Existing implementations are conforming and there are no > interoperability problems with a timer that can be set to more than > one value. rfc1264 is quite clear on this topic: 4) There must be evidence that all features of the protocol have been tested, running between at least two implementations. Note that the above quote does not distinguish between SHOULD and MUST features. > I understand that you don't want to change the spec. Again. I have no problem with changing the spec, as long as the change reflects what is implemented and deployed. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA22585 for ; Sat, 28 Feb 2004 20:23:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEYr-0004hA-5e; Sat, 28 Feb 2004 19:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEYO-0004gh-Dq for idr@optimus.ietf.org; Sat, 28 Feb 2004 19:11:32 -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 TAA11721 for ; Sat, 28 Feb 2004 19:11:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEYK-0004B9-00 for idr@ietf.org; Sat, 28 Feb 2004 19:11:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEXT-00046M-00 for idr@ietf.org; Sat, 28 Feb 2004 19:10:36 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AxEX2-0003zt-00 for idr@ietf.org; Sat, 28 Feb 2004 19:10:08 -0500 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 i1T09PBm011123; Sat, 28 Feb 2004 16:09:25 -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 i1T09Oo29392; Sat, 28 Feb 2004 16:09:24 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402290009.i1T09Oo29392@merlot.juniper.net> To: curtis@fictitious.org cc: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: Your message of "Fri, 27 Feb 2004 02:22:57 EST." <200402270722.i1R7MvRX031806@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61529.1078013364.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=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: Sat, 28 Feb 2004 16:09:24 -0800 Curtis, [clipped...] > Pedro, > > If you have separate timers for route origination/advertisement and > up/down and the best solution is to set them all the same then it is > possible to set them all the same. > > If you specify that they must be the same and that doesn't turn out to > be the best way to do things you are stuck. > > Its clear that there isn't agreement on the best solution, so for the > time being flexibility is needed. One point to keep in mind is that since we are moving the spec to a Draft Standard, a *necessary* condition for relaxing the spec to support the flexibility you mentioned above would be more than one implementation that supports such flexibility. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21507 for ; Sat, 28 Feb 2004 17:54:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDLM-0001L8-S6; Sat, 28 Feb 2004 17:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax9AI-0001Wa-Er for idr@optimus.ietf.org; Sat, 28 Feb 2004 13:26:18 -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 NAA26661 for ; Sat, 28 Feb 2004 13:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax9AG-0006Yr-00 for idr@ietf.org; Sat, 28 Feb 2004 13:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax99N-0006S3-00 for idr@ietf.org; Sat, 28 Feb 2004 13:25:22 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Ax991-0006Mp-00 for idr@ietf.org; Sat, 28 Feb 2004 13:24:59 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1SIO7RX049414; Sat, 28 Feb 2004 13:24:07 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402281824.i1SIO7RX049414@workhorse.fictitious.org> To: Parantap Lahiri cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 27 Feb 2004 15:26:56 EST." <00b801c3fd70$0badcd50$c8922799@mcilink.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Sat, 28 Feb 2004 13:24:07 -0500 In message <00b801c3fd70$0badcd50$c8922799@mcilink.com>, Parantap Lahiri writes : > The problem Pekka is describing is definitely a very valid problem which > exists. I am not sure though if the fix is in some design modifications or > in fixing the spec itself. > > The ways to fix it by design modification would be ... > > The router R1 in question resets the BGP next-hop to some secondary loopback > address which is different from the primary loopback (part of the prefix/16) > and the secondary loopback address range is only in IGP as discrete /32s, > this problem might be mitigated. Though it's going to load the IGP with a > new set of IP prefixes and may be problematic in some situations since some > IGP protocols have limited capability to carry large number of IP prefixes. > > The other way to solve it might be a vendor implemented knob, where a > particular address range (like prefix/16) is never considered while doing > BGP next hop resolution. Though, I am not sure if this knob would be a part > of the spec. > > -Parantap I'm not sure what that has to do with discard routes unless you are talking about generating an aggregate and the next hop falling into the unused portion of the aggregate. If you allow the next hop to resolved to the unused portion of an aggregated, your implementation is simply broken. You can't forward on a aggregate you generate, you can only forward on the components that make up the aggregate and if you miss this distinction in your BGP implementation, that is just an implementation mistake. If OTOH, some other router did the aggregation and sent the aggregate into the IGP or IBGP, then the problem is not one that needs to be fixed in the spec. If allowing BGP learned routes to resolve BGP next hops, which is commonly configured, another knob that can be added is to exclude routes in which the aggregator is in the same AS. If that was not sufficient you'd need a knob to exclude specific prefixes. This is clearly outside of the BGP spec. It seems to me to be more a case of adding configuration knobs to cover up the problems caused by misconfiguration. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21506 for ; Sat, 28 Feb 2004 17:54:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDLM-0001L0-8Y; Sat, 28 Feb 2004 17:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax8t3-0000e6-Bx for idr@optimus.ietf.org; Sat, 28 Feb 2004 13:08:29 -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 NAA26082 for ; Sat, 28 Feb 2004 13:08:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax8t1-0004j2-00 for idr@ietf.org; Sat, 28 Feb 2004 13:08:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax8s0-0004cT-00 for idr@ietf.org; Sat, 28 Feb 2004 13:07:25 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Ax8rE-0004WG-00 for idr@ietf.org; Sat, 28 Feb 2004 13:06:36 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1SI5cRX049251; Sat, 28 Feb 2004 13:05:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402281805.i1SI5cRX049251@workhorse.fictitious.org> To: Pekka Savola cc: "John G. Scudder" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 In-reply-to: Your message of "Sat, 28 Feb 2004 08:41:33 +0200." From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Sat, 28 Feb 2004 13:05:38 -0500 In message , Pekka Savola writes: > > By default, the route resolvability check typically fails if there > exists any less specific route to the next-hop, e.g., if it is > covered by a default discard or an aggregate route. Therefore, it > SHOULD be configurable which routes are used to check whether the > next-hops are resolvable. For example, one might want to use only > local, "connected" and IGP routes, or one might want to remove > discard routes from consideration. If the next hop is covered by a discard route it is considered unresolvable. I'm not sure I understand why this is a problem. I used to be involved in operating a large ISP or two and I can't remember any instance in which we (intentionally or otherwise) installed a discard route that covered one of our BGP peers. If we did install such a route, that route would have cause so much trouble that it got removed within minutes and the person that added it would probably not want to make that fact widely known. Is there something I'm missing? Is there actually a legitimate reason that you would install a discard route that covered either your BGP peer's address or some address that your BGP peer would decide to use as a next hop? Do people normally install discard routes covering their IBGP peer's addresses? [That last one was a bit of a rhetorical question]. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17744 for ; Sat, 28 Feb 2004 09:48:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l6-00087h-R2; Sat, 28 Feb 2004 09:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awogr-0003Cc-Ez for idr@optimus.ietf.org; Fri, 27 Feb 2004 15:34:33 -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 PAA23082 for ; Fri, 27 Feb 2004 15:34:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awogq-0001yc-00 for idr@ietf.org; Fri, 27 Feb 2004 15:34:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awofv-0001uB-00 for idr@ietf.org; Fri, 27 Feb 2004 15:33:35 -0500 Received: from omzesmtp01.mci.com ([199.249.17.7]) by ietf-mx with esmtp (Exim 4.12) id 1Awofl-0001pE-00 for idr@ietf.org; Fri, 27 Feb 2004 15:33:26 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTR0090UFGXZ9@firewall.mci.com> for idr@ietf.org; Fri, 27 Feb 2004 20:26:58 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTR00001FGWXT@dgismtp06.mcilink.com>; Fri, 27 Feb 2004 20:26:57 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTR0008KFGWBI@dgismtp06.mcilink.com>; Fri, 27 Feb 2004 20:26:57 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: To: "'Pekka Savola'" , "'John G. Scudder'" Cc: idr@ietf.org Message-id: <00b801c3fd70$0badcd50$c8922799@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=iso-8859-1 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=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: Fri, 27 Feb 2004 15:26:56 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA17744 The problem Pekka is describing is definitely a very valid problem which exists. I am not sure though if the fix is in some design modifications or in fixing the spec itself. The ways to fix it by design modification would be ... The router R1 in question resets the BGP next-hop to some secondary loopback address which is different from the primary loopback (part of the prefix/16) and the secondary loopback address range is only in IGP as discrete /32s, this problem might be mitigated. Though it's going to load the IGP with a new set of IP prefixes and may be problematic in some situations since some IGP protocols have limited capability to carry large number of IP prefixes. The other way to solve it might be a vendor implemented knob, where a particular address range (like prefix/16) is never considered while doing BGP next hop resolution. Though, I am not sure if this knob would be a part of the spec. -Parantap -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Pekka Savola Sent: Friday, February 27, 2004 3:01 PM To: John G. Scudder Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes On Fri, 27 Feb 2004, John G. Scudder wrote: > >.. the problem is that unless you have full routing table in every > >router, and no default discard/aggregate routes/etc., this works.  > >Otherwise when your IBGP neighbor goes down, the BGP routes learned > >from that neighbor stay in the BGP table until the BGP session is > >reset after 90 seconds or so. Instead, the routes should immediately > >be removed from BGP when the loopback address is removed from the IGP. > > I agree with your final sentence; however, I > don't understand the other parts of that > paragraph, nor how your proposed text would help > it. Ok. Let me try to clarify the situation. Assume router R1 in the AS has some a route, route_r1, which it sends to every iBGP router. Router R1 goes down. OSPF notices that R1 has gone down, as its loopback address has been removed from OSPF. Assume that a core router or two in the AS has been set up with a couple of "null0" routes, for the purposes of aggregation, or default route redistribution, e.g., "prefix/16" or "0/0". Assume that the nexthop of route_r1 matches these null0 routes. Now, all other routers in the AS keep route_r1 in their routing table as long as the BGP session stays up (some 90 seconds or so), because its nexthop, the loopback address of R1 -- while no longer available with OSPF, is still recursively resolvable through either one of the null0 routes. This causes a major problem. This implies that for BGP to function properly, the loopback or point-to-point addresses MUST NOT have any less-specific routes which could be considered unresolvable if the main route itself is removed from IGP. > In fact, I don't think there is a problem in > the spec as it stands with IBGP routes which > resolve to a loopback -- these are covered by > 9.1.2.1(1). When the loopback address is removed from OSPF, the next best route is the static default discard route (or something like that) -- which is an interface route. > As others have mentioned, if a route > resolves to null0 or the like, this is presumably > the result of deliberate configuration and > certainly not something we want to preclude in > the spec. Yep, this causes a problem with the DDoS mitigation method described earlier, so I'm not sure what the right fix is. However, it clearly seems to call for a requirement to be able to specify, somehow, which routes should be used when considering resolvability (e.g., just connected and IGP routes, ...). -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17725 for ; Sat, 28 Feb 2004 09:48: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 1Ax5l3-00084X-Gg; Sat, 28 Feb 2004 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcNA-0000JV-0p for idr@optimus.ietf.org; Fri, 27 Feb 2004 02:25: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 CAA17774 for ; Fri, 27 Feb 2004 02:25:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcN6-0005m2-00 for idr@ietf.org; Fri, 27 Feb 2004 02:25:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcMA-0005el-00 for idr@ietf.org; Fri, 27 Feb 2004 02:24:22 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AwcLG-0005YW-00 for idr@ietf.org; Fri, 27 Feb 2004 02:23:26 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1R7MvRX031806; Fri, 27 Feb 2004 02:22:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> To: Pedro Roque Marques cc: curtis@fictitious.org, idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Thu, 26 Feb 2004 22:50:11 PST." <200402270650.i1R6oBuU039747@roque-bsd.juniper.net> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Fri, 27 Feb 2004 02:22:57 -0500 In message <200402270650.i1R6oBuU039747@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > Curtis Villamizar writes: > > > If withdraws propogate faster first the unfeasible AS paths are > > removed, then the feasible ones start propogating. The result is > > some withdraw followed by add but much less AS path change in the > > presence of cycles. > > The point in which we differ is that you equate withdraws and updates > w/ unfeasible and feasible paths. I don't believe one can make that > assumption. > > For a given AS, if you have as input an withdraw that can result in an > update being generated or vice-versa, depending on the policy. > > You can have a link up event result in withdrawns being generated, and > a link down event result in updates. In other words the addition of > feasible paths, can result via policy, in withdrawls. > > > Providing separate timers allows us to defer the question of which > > is preferable. > > Providing separate timers, imho, will just further confuse the issue > :-). It has already been showen that there is no single choice of MRAI > timer that is appropriate for all situations. Now you propose an > additional one. That is two parameters nobody knows what the optimal > setting should be. > > Furthermore, i believe that, due to the meshed nature of internet > connectivity, using different delays may increase the duration of > transients. > > Lets say that you start w/ a current path through as3 and > you have a link up event (a) that brings up a prefered path. > > as 3 > | > --a-> as 1 --> as 4 > > --a-> as 2 --> as 4 > > If a is a peer route for as 1 but a customer route for as 2, then by > propagating the withdrawl faster you are increasing the transient time > and causing increase connectivity to create a blackhole for as4. > > imho, currently there is only one good known value for MRAI for both > updates and withdrawls, and that is 0. Let BGP speakers propagate > updates as fast as they can, taking into account that BGP itself > already has embedded flow control mechanisms that allow a receiver to > pace a sender appropriatly. > > Unfortunatly, even that setting (0) has its drawbacks. One is that > values should probably be consistent within an as, and there are very > different interpretations of MRAI between different vendors. The > second is that in case of MED oscillations, MRAI helps reduce the > ammount of churn. > > regards, > Pedro. Pedro, If you have separate timers for route origination/advertisement and up/down and the best solution is to set them all the same then it is possible to set them all the same. If you specify that they must be the same and that doesn't turn out to be the best way to do things you are stuck. Its clear that there isn't agreement on the best solution, so for the time being flexibility is needed. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17726 for ; Sat, 28 Feb 2004 09:48: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 1Ax5l5-00084v-JU; Sat, 28 Feb 2004 09:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awnoi-0007A8-No for idr@optimus.ietf.org; Fri, 27 Feb 2004 14:38: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 OAA19599 for ; Fri, 27 Feb 2004 14:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awnog-00037V-00 for idr@ietf.org; Fri, 27 Feb 2004 14:38:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awnnt-00032A-00 for idr@ietf.org; Fri, 27 Feb 2004 14:37:46 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AwnnJ-0002vm-00 for idr@ietf.org; Fri, 27 Feb 2004 14:37:10 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1RJaTRX037523; Fri, 27 Feb 2004 14:36:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402271936.i1RJaTRX037523@workhorse.fictitious.org> To: "John G. Scudder" cc: Pekka Savola , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 27 Feb 2004 13:10:07 EST." From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Fri, 27 Feb 2004 14:36:28 -0500 In message , "John G. Scudder" writes: > Pekka, > > I'm confused -- to my eye, the spec change you propose: > > At 9:01 AM +0200 2/27/04, Pekka Savola wrote: > >Hi, > > > >We analyzed one source of operational BGP problems and noticed a > >problem which should be made explicit in the BGP specification. > > > >In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1: > > > > 2. Routes referencing interfaces (with or without intermediate > > addresses) are considered resolvable if the state of the refer- > > enced interface is up and IP processing is enabled on this inter- > > face. > > > >I propose adding something like: > > > > For the purposes of this check, the routes for which > > packets are discarded by the router (i.e., "null" or "discard" > > routes) SHOULD be considered unresolvable. > > Doesn't correspond to the problem you describe: > > >.. the problem is that unless you have full routing table in every > >router, and no default discard/aggregate routes/etc., this works.  > >Otherwise when your IBGP neighbor goes down, the BGP routes learned > >from that neighbor stay in the BGP table until the BGP session is > >reset after 90 seconds or so. Instead, the routes should immediately > >be removed from BGP when the loopback address is removed from the IGP. > > I agree with your final sentence; however, I > don't understand the other parts of that > paragraph, nor how your proposed text would help > it. In fact, I don't think there is a problem in > the spec as it stands with IBGP routes which > resolve to a loopback -- these are covered by > 9.1.2.1(1). As others have mentioned, if a route > resolves to null0 or the like, this is presumably > the result of deliberate configuration and > certainly not something we want to preclude in > the spec. > > Maybe you could expand further on what you think the problem is. > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr You can never advertise a discard route to a BGP peer which makes sense but the text in 9.1.2.1 doesn't deal with advertisement. If you have a discard route, you probably put it there for a reason and therefore you don't want to exclude that router from the decision process. It doesn't really come into play in this decision. The discard route would override the best BGP route. It would often be a more specific route, maybe a /32. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17723 for ; Sat, 28 Feb 2004 09:48:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l4-00084f-2p; Sat, 28 Feb 2004 09:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkbG-0002ou-Pj for idr@optimus.ietf.org; Fri, 27 Feb 2004 11:12:30 -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 LAA10786 for ; Fri, 27 Feb 2004 11:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkbF-0001uB-00 for idr@ietf.org; Fri, 27 Feb 2004 11:12:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkaI-0001nW-00 for idr@ietf.org; Fri, 27 Feb 2004 11:11:31 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AwkZt-0001hw-00 for idr@ietf.org; Fri, 27 Feb 2004 11:11:05 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1RGA9RX036811; Fri, 27 Feb 2004 11:10:09 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402271610.i1RGA9RX036811@workhorse.fictitious.org> To: raszuk@cisco.com cc: curtis@fictitious.org, Pedro Roque Marques , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Fri, 27 Feb 2004 02:54:49 PST." <403F21F9.6000903@cisco.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Fri, 27 Feb 2004 11:10:09 -0500 In message <403F21F9.6000903@cisco.com>, Robert Raszuk writes: > Curtis, > > > Where this matters is if there is a cycle: > > > > AS1 -- AS2 -- AS3 -- AS4 -- AS5 -- ASn -- back to AS1 > > I am glad there seems to be an agreement that providing two timers may > matter in the long chain of ASes. > > I also therefor assume that there is an agreement that within single AS > or even short chain of 1-3 ASes connected to each other the most > practical would be not to introduce two delays one for updates/implicit > withdraws and the other for updates with only unreachable routes. > > While maybe in the case you mentioned indeed there could be some > benefits but I think correctly setting those timers in an uniform way > across all of those ASes is just not possible to be achieved in practice. > > It also seems that different settings in each AS (some of them maybe due > to errors) may produce much worse outcome that not using any timer at > all. Therefor unless we come up with some auto-tuning way I am not sure > if we should treat pure withdraws any different then implicit withdraws > or reachability information. > > Rgs, > R. Robert, What I'm saying is we know cases where the impact would be dramatic and the Craig and Ahba and other Sigcomm papers on BGP performance show plenty of evidence that these cases quite commonly occur on the network. Until the research/standards/operators/vendor community *decides* what is truly the best way to provide these timers, setting the same for up and down or different, we should provide the flexibility in the spec and should provide the flexibility in implementations. Evidence points to significant benefits to separate timers but that's not the main issue. The issue is providing sufficient flexibility such that if this is beneficial the spec doesn't preclude it. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17724 for ; Sat, 28 Feb 2004 09:48:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l4-00084n-QX; Sat, 28 Feb 2004 09:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwmzS-0003vg-Nd for idr@optimus.ietf.org; Fri, 27 Feb 2004 13:45:38 -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 NAA17832 for ; Fri, 27 Feb 2004 13:45:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwmzQ-0004yy-00 for idr@ietf.org; Fri, 27 Feb 2004 13:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awmyf-0004sy-00 for idr@ietf.org; Fri, 27 Feb 2004 13:44:49 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Awmy1-0004ld-00 for idr@ietf.org; Fri, 27 Feb 2004 13:44:10 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1RIhTRX037110; Fri, 27 Feb 2004 13:43:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402271843.i1RIhTRX037110@workhorse.fictitious.org> To: raszuk@cisco.com cc: Pekka Savola , Pedro Roque Marques , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 27 Feb 2004 02:33:31 PST." <403F1CFB.4070107@cisco.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Fri, 27 Feb 2004 13:43:28 -0500 In message <403F1CFB.4070107@cisco.com>, Robert Raszuk writes: > > http://www.securite.org/presentations/secip/BHAMS2001-SecIP-v105-full.ppt Robert, This file is in some sort of strange proprietary format. Was that a mistake? :-) Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA13944 for ; Sat, 28 Feb 2004 01:44:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwyCf-0006qp-3I; Sat, 28 Feb 2004 01:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwyCa-0006qc-Cq for idr@optimus.ietf.org; Sat, 28 Feb 2004 01:43:56 -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 BAA20108 for ; Sat, 28 Feb 2004 01:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwyCX-0001AC-00 for idr@ietf.org; Sat, 28 Feb 2004 01:43:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwyBY-00014v-00 for idr@ietf.org; Sat, 28 Feb 2004 01:42:53 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwyB1-0000v0-00 for idr@ietf.org; Sat, 28 Feb 2004 01:42:19 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1S6fXP24756; Sat, 28 Feb 2004 08:41:33 +0200 From: Pekka Savola To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 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: Sat, 28 Feb 2004 08:41:33 +0200 (EET) On Fri, 27 Feb 2004, John G. Scudder wrote: > >specify, somehow, which routes should be used when considering > >resolvability (e.g., just connected and IGP routes, ...). > > GateD 3.5.x used to require exactly that. In my experience this > "feature" was by far the single biggest source of operational pain > and confusion when using GateD BGP. Probably yes, if it's the default, and not understood by the users. > Also, consider that this proposes that the router operator go to some > trouble to consider and configure which routes can and can't be used > for resolution. Any larger network operator already has this kind of consistent design: e.g., all the routes are in your IGP, and if they aren't that's an error condition which must be fixed. > That work could (IMO) equally be put into designing > their routing such that their infrastructure loopbacks aren't covered > by an aggregate. This has the merit of being something that can be > done today with no further spec or implementation work. The only way to achieve this sensibly would be using some kind of private addresses between the iBGP sessions which is IMHO a bad idea -- it adds routes to IGP, and you really shouldn't have to be doing that in any case. > More elaborate solutions could certainly be contemplated but I'm not > sure they're worth the pain. IMHO, as this is an obviously a real operational problem, it should be mentioned in the BGP spec, at least in some length. For example, in 9.1.2.1: By default, the route resolvability check typically fails if there exists any less specific route to the next-hop, e.g., if it is covered by a default discard or an aggregate route. Therefore, it SHOULD be configurable which routes are used to check whether the next-hops are resolvable. For example, one might want to use only local, "connected" and IGP routes, or one might want to remove discard routes from consideration. Would something like that make sense? FWIW, I'm considering whether to start writing a BCP/Info draft on how to improve your IGP/BGP convergence/stability, and which pitfalls (like this one!) to avoid, but that's beyond the scope of this WG. If anyone has strong feelings whether would be a good or bad idea, send them to me off-list. -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA10982 for ; Fri, 27 Feb 2004 19:05:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwryY-00076U-AC; Fri, 27 Feb 2004 19:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwryC-00074K-Em for idr@optimus.ietf.org; Fri, 27 Feb 2004 19:04:40 -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 TAA05235 for ; Fri, 27 Feb 2004 19:04:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awry9-0004CI-00 for idr@ietf.org; Fri, 27 Feb 2004 19:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwrxA-00045B-00 for idr@ietf.org; Fri, 27 Feb 2004 19:03:37 -0500 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 1AwrwC-0003uM-00 for idr@ietf.org; Fri, 27 Feb 2004 19:02:36 -0500 Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id ; Fri, 27 Feb 2004 19:02:06 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35071A2865@entmail.gnilink.net> From: "Martin, Christian" To: "'John G. Scudder'" , "'Pekka Savola'" Cc: "'idr@ietf.org'" , "'raszuk@cisco.com'" Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: Fri, 27 Feb 2004 19:02:05 -0500 John, Pekka, >Also, consider that this proposes that the router operator go to some >trouble to consider and configure which routes can and can't be used >for resolution. That work could (IMO) equally be put into designing >their routing such that their infrastructure loopbacks aren't covered >by an aggregate. I would also argue that it is at best improbable that a loopback is NOT covered by an aggregate, as usually these addresses are announced for (at a minimum) ICMP message sources outside the domain. I must agree that this is out of spec and better suited to a subsequent applicability statement, or perhaps handled in GROW. Better yet, let's leave it to the vendors to implement as a knob. John, Robert - are you listening? ;) Chris >_______________________________________________ >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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09185 for ; Fri, 27 Feb 2004 15:19:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwoRp-0001ON-8K; Fri, 27 Feb 2004 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwoRP-0001Ge-0b for idr@optimus.ietf.org; Fri, 27 Feb 2004 15:18:35 -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 PAA22276 for ; Fri, 27 Feb 2004 15:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwoRN-00003c-00 for idr@ietf.org; Fri, 27 Feb 2004 15:18:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwoQW-0007kS-00 for idr@ietf.org; Fri, 27 Feb 2004 15:17:41 -0500 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 1AwoPc-0007WL-00 for idr@ietf.org; Fri, 27 Feb 2004 15:16:44 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2004 12:26:58 +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 i1RKGCuA012295; Fri, 27 Feb 2004 12:16:12 -0800 (PST) Received: from [192.168.42.3] (dhcp-64-101-214-212.cisco.com [64.101.214.212]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA09488; Fri, 27 Feb 2004 15:16:11 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 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=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: Fri, 27 Feb 2004 15:15:50 -0500 At 10:00 PM +0200 2/27/04, Pekka Savola wrote: >Ok. Let me try to clarify the situation. [thanks, that's clear] >However, it clearly seems to call for a requirement to be able to >specify, somehow, which routes should be used when considering >resolvability (e.g., just connected and IGP routes, ...). GateD 3.5.x used to require exactly that. In my experience this "feature" was by far the single biggest source of operational pain and confusion when using GateD BGP. Also, consider that this proposes that the router operator go to some trouble to consider and configure which routes can and can't be used for resolution. That work could (IMO) equally be put into designing their routing such that their infrastructure loopbacks aren't covered by an aggregate. This has the merit of being something that can be done today with no further spec or implementation work. More elaborate solutions could certainly be contemplated but I'm not sure they're worth the pain. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09175 for ; Fri, 27 Feb 2004 15:17:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwoPt-0000oW-2K; Fri, 27 Feb 2004 15:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwoPV-0000iU-3S for idr@optimus.ietf.org; Fri, 27 Feb 2004 15:16:37 -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 PAA22028 for ; Fri, 27 Feb 2004 15:16:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwoPT-0007bN-00 for idr@ietf.org; Fri, 27 Feb 2004 15:16:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwoOV-0007Ta-00 for idr@ietf.org; Fri, 27 Feb 2004 15:15:35 -0500 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 1AwoNb-0007Hs-00 for idr@ietf.org; Fri, 27 Feb 2004 15:14:39 -0500 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 i1RKE4uA010021; Fri, 27 Feb 2004 12:14:05 -0800 (PST) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS32312; Fri, 27 Feb 2004 12:14:00 -0800 (PST) Message-ID: <403FA505.1020001@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: Pekka Savola CC: "John G. Scudder" , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 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.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, 27 Feb 2004 12:13:57 -0800 Thx Pekka, > Assume that the nexthop of route_r1 matches these null0 routes. Now your issue is clear ;). But it seems to that this is just an implementation issue not the spec issue. Further one operator may need to resolve via a summary route covering loopback while someone else may not wish to do so and always INVALIDATE all BGP routes when their /32 next hops are removed from IGP. I don't think we can put anywhere in the spec a hard line that BGP next hops must be valid only if their /32s are in the RIB :). I don't think any spec update is required. At most simple few lines of code in the vendor of your choice ;-). Cheers, R. > Pekka Savola wrote: > > On Fri, 27 Feb 2004, John G. Scudder wrote: > >>>.. the problem is that unless you have full routing table in every >>>router, and no default discard/aggregate routes/etc., this works. >>>Otherwise when your IBGP neighbor goes down, the BGP routes learned >> >>>from that neighbor stay in the BGP table until the BGP session is >> >>>reset after 90 seconds or so. Instead, the routes should immediately >>>be removed from BGP when the loopback address is removed from the IGP. >> >>I agree with your final sentence; however, I >>don't understand the other parts of that >>paragraph, nor how your proposed text would help >>it. > > > Ok. Let me try to clarify the situation. Assume router R1 in the AS > has some a route, route_r1, which it sends to every iBGP router. > Router R1 goes down. OSPF notices that R1 has gone down, as its > loopback address has been removed from OSPF. > > Assume that a core router or two in the AS has been set up with a > couple of "null0" routes, for the purposes of aggregation, or default > route redistribution, e.g., "prefix/16" or "0/0". > > Assume that the nexthop of route_r1 matches these null0 routes. > > Now, all other routers in the AS keep route_r1 in their routing table > as long as the BGP session stays up (some 90 seconds or so), because > its nexthop, the loopback address of R1 -- while no longer available > with OSPF, is still recursively resolvable through either one of the > null0 routes. > > This causes a major problem. This implies that for BGP to function > properly, the loopback or point-to-point addresses MUST NOT have any > less-specific routes which could be considered unresolvable if the > main route itself is removed from IGP. > > >>In fact, I don't think there is a problem in >>the spec as it stands with IBGP routes which >>resolve to a loopback -- these are covered by >>9.1.2.1(1). > > > When the loopback address is removed from OSPF, the next best route is > the static default discard route (or something like that) -- which is > an interface route. > > >>As others have mentioned, if a route >>resolves to null0 or the like, this is presumably >>the result of deliberate configuration and >>certainly not something we want to preclude in >>the spec. > > > Yep, this causes a problem with the DDoS mitigation method described > earlier, so I'm not sure what the right fix is. > > However, it clearly seems to call for a requirement to be able to > specify, somehow, which routes should be used when considering > resolvability (e.g., just connected and IGP routes, ...). > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09053 for ; Fri, 27 Feb 2004 15:04:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwoDJ-0004Dm-98; Fri, 27 Feb 2004 15:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwoCy-00041m-Sx for idr@optimus.ietf.org; Fri, 27 Feb 2004 15:03:40 -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 PAA20379 for ; Fri, 27 Feb 2004 15:03:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwoCv-0005q2-00 for idr@ietf.org; Fri, 27 Feb 2004 15:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwoBv-0005jE-00 for idr@ietf.org; Fri, 27 Feb 2004 15:02:36 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwoBB-0005Yv-00 for idr@ietf.org; Fri, 27 Feb 2004 15:01:49 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1RK0qI16627; Fri, 27 Feb 2004 22:00:52 +0200 From: Pekka Savola To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id i1RK0qI16627 X-Spam-Checker-Version: SpamAssassin 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, 27 Feb 2004 22:00:52 +0200 (EET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA09053 On Fri, 27 Feb 2004, John G. Scudder wrote: > >.. the problem is that unless you have full routing table in every > >router, and no default discard/aggregate routes/etc., this works.  > >Otherwise when your IBGP neighbor goes down, the BGP routes learned > >from that neighbor stay in the BGP table until the BGP session is > >reset after 90 seconds or so. Instead, the routes should immediately > >be removed from BGP when the loopback address is removed from the IGP. > > I agree with your final sentence; however, I > don't understand the other parts of that > paragraph, nor how your proposed text would help > it. Ok. Let me try to clarify the situation. Assume router R1 in the AS has some a route, route_r1, which it sends to every iBGP router. Router R1 goes down. OSPF notices that R1 has gone down, as its loopback address has been removed from OSPF. Assume that a core router or two in the AS has been set up with a couple of "null0" routes, for the purposes of aggregation, or default route redistribution, e.g., "prefix/16" or "0/0". Assume that the nexthop of route_r1 matches these null0 routes. Now, all other routers in the AS keep route_r1 in their routing table as long as the BGP session stays up (some 90 seconds or so), because its nexthop, the loopback address of R1 -- while no longer available with OSPF, is still recursively resolvable through either one of the null0 routes. This causes a major problem. This implies that for BGP to function properly, the loopback or point-to-point addresses MUST NOT have any less-specific routes which could be considered unresolvable if the main route itself is removed from IGP. > In fact, I don't think there is a problem in > the spec as it stands with IBGP routes which > resolve to a loopback -- these are covered by > 9.1.2.1(1). When the loopback address is removed from OSPF, the next best route is the static default discard route (or something like that) -- which is an interface route. > As others have mentioned, if a route > resolves to null0 or the like, this is presumably > the result of deliberate configuration and > certainly not something we want to preclude in > the spec. Yep, this causes a problem with the DDoS mitigation method described earlier, so I'm not sure what the right fix is. However, it clearly seems to call for a requirement to be able to specify, somehow, which routes should be used when considering resolvability (e.g., just connected and IGP routes, ...). -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08197 for ; Fri, 27 Feb 2004 13:13: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 1AwmTs-0002F2-PG; Fri, 27 Feb 2004 13:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwmTU-0002BJ-3N for idr@optimus.ietf.org; Fri, 27 Feb 2004 13:12: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 NAA16441 for ; Fri, 27 Feb 2004 13:12:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwmTS-00011f-00 for idr@ietf.org; Fri, 27 Feb 2004 13:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwmSV-0000vJ-00 for idr@ietf.org; Fri, 27 Feb 2004 13:11:35 -0500 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 1AwmRg-0000lA-00 for idr@ietf.org; Fri, 27 Feb 2004 13:10:44 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2004 10:20:57 +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 i1RIACuA008866; Fri, 27 Feb 2004 10:10:12 -0800 (PST) Received: from [192.168.42.3] (dhcp-64-101-214-212.cisco.com [64.101.214.212]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA03118; Fri, 27 Feb 2004 13:10:11 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Cc: idr@ietf.org 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=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: Fri, 27 Feb 2004 13:10:07 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA08197 Pekka, I'm confused -- to my eye, the spec change you propose: At 9:01 AM +0200 2/27/04, Pekka Savola wrote: >Hi, > >We analyzed one source of operational BGP problems and noticed a >problem which should be made explicit in the BGP specification. > >In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1: > > 2. Routes referencing interfaces (with or without intermediate > addresses) are considered resolvable if the state of the refer- > enced interface is up and IP processing is enabled on this inter- > face. > >I propose adding something like: > > For the purposes of this check, the routes for which > packets are discarded by the router (i.e., "null" or "discard" > routes) SHOULD be considered unresolvable. Doesn't correspond to the problem you describe: >.. the problem is that unless you have full routing table in every >router, and no default discard/aggregate routes/etc., this works.  >Otherwise when your IBGP neighbor goes down, the BGP routes learned >from that neighbor stay in the BGP table until the BGP session is >reset after 90 seconds or so. Instead, the routes should immediately >be removed from BGP when the loopback address is removed from the IGP. I agree with your final sentence; however, I don't understand the other parts of that paragraph, nor how your proposed text would help it. In fact, I don't think there is a problem in the spec as it stands with IBGP routes which resolve to a loopback -- these are covered by 9.1.2.1(1). As others have mentioned, if a route resolves to null0 or the like, this is presumably the result of deliberate configuration and certainly not something we want to preclude in the spec. Maybe you could expand further on what you think the problem is. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA05940 for ; Fri, 27 Feb 2004 08:50: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 1AwiNP-0003i7-Ai; Fri, 27 Feb 2004 08:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiMg-0003gl-0u for idr@optimus.ietf.org; Fri, 27 Feb 2004 08:49:18 -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 IAA01708 for ; Fri, 27 Feb 2004 08:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwiMe-0006ek-00 for idr@ietf.org; Fri, 27 Feb 2004 08:49:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwiLg-0006Z5-00 for idr@ietf.org; Fri, 27 Feb 2004 08:48:16 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AwiKh-0006QC-00 for idr@ietf.org; Fri, 27 Feb 2004 08:47:15 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B9E672D48C1 for ; Fri, 27 Feb 2004 08:46:44 -0500 (EST) 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 60523-02-15 for ; Fri, 27 Feb 2004 08:46:43 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 03A4F2D480C for ; Fri, 27 Feb 2004 08:46:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm Thread-Index: AcP9NOXemsH1JBsuQle9rueCDj73bgAAyQgQ From: "Susan Hares" To: "Alex Zinin" 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: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 27 Feb 2004 08:46:42 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id IAA05940 I think it would be a useful addition to the discussion. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Friday, February 27, 2004 3:16 AM To: Susan Hares Cc: idr@ietf.org; dhares@ndzh.com; fenner@research.att.com Subject: Re: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm Sue- > 6) BGP Assignment of AFI/SAFI address [10 minutes] > Document: draft-hares-bgp-assign-afisafi-00.txt (ietf) (-01 on web site) > Author: Susan Hares I'm wondering if we should also discuss allocation of BGP attribute codes and suggested procedures in draft-kompella-zinin-early-allocation-00.txt. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA05738 for ; Fri, 27 Feb 2004 08:26:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awi0B-0001aU-19; Fri, 27 Feb 2004 08:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhzR-0001Yx-JD for idr@optimus.ietf.org; Fri, 27 Feb 2004 08:25:17 -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 IAA00076 for ; Fri, 27 Feb 2004 08:25:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwhzQ-0003gg-00 for idr@ietf.org; Fri, 27 Feb 2004 08:25:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwhyT-0003aQ-00 for idr@ietf.org; Fri, 27 Feb 2004 08:24:17 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AwhxZ-0003VE-00 for idr@ietf.org; Fri, 27 Feb 2004 08:23:22 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Awhx9-000NCF-D4; Fri, 27 Feb 2004 13:22:55 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1184871755.20040227171553@psg.com> To: "Susan Hares" CC: idr@ietf.org, dhares@ndzh.com, fenner@research.att.com In-Reply-To: References: 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,DATE_IN_PAST_03_06, RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 27 Feb 2004 17:15:53 +0900 Sue- > 6) BGP Assignment of AFI/SAFI address [10 minutes] > Document: draft-hares-bgp-assign-afisafi-00.txt (ietf) (-01 on web site) > Author: Susan Hares I'm wondering if we should also discuss allocation of BGP attribute codes and suggested procedures in draft-kompella-zinin-early-allocation-00.txt. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA04488 for ; Fri, 27 Feb 2004 05:58:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awfgv-0007bz-40; Fri, 27 Feb 2004 05:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfgD-0007VC-9p for idr@optimus.ietf.org; Fri, 27 Feb 2004 05:57:17 -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 FAA25460 for ; Fri, 27 Feb 2004 05:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awfg9-00041J-00 for idr@ietf.org; Fri, 27 Feb 2004 05:57:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwffD-0003wO-00 for idr@ietf.org; Fri, 27 Feb 2004 05:56:15 -0500 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 1AwfeQ-0003n7-00 for idr@ietf.org; Fri, 27 Feb 2004 05:55:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2004 03:06:19 +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 i1RAss4U008603; Fri, 27 Feb 2004 02:54:55 -0800 (PST) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR90182; Fri, 27 Feb 2004 02:54:52 -0800 (PST) Message-ID: <403F21F9.6000903@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: curtis@fictitious.org CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer References: <200402270525.i1R5PCRX031392@workhorse.fictitious.org> In-Reply-To: <200402270525.i1R5PCRX031392@workhorse.fictitious.org> 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: Fri, 27 Feb 2004 02:54:49 -0800 Curtis, > Where this matters is if there is a cycle: > > AS1 -- AS2 -- AS3 -- AS4 -- AS5 -- ASn -- back to AS1 I am glad there seems to be an agreement that providing two timers may matter in the long chain of ASes. I also therefor assume that there is an agreement that within single AS or even short chain of 1-3 ASes connected to each other the most practical would be not to introduce two delays one for updates/implicit withdraws and the other for updates with only unreachable routes. While maybe in the case you mentioned indeed there could be some benefits but I think correctly setting those timers in an uniform way across all of those ASes is just not possible to be achieved in practice. It also seems that different settings in each AS (some of them maybe due to errors) may produce much worse outcome that not using any timer at all. Therefor unless we come up with some auto-tuning way I am not sure if we should treat pure withdraws any different then implicit withdraws or reachability information. Rgs, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA04301 for ; Fri, 27 Feb 2004 05:38:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfNa-0006D6-QM; Fri, 27 Feb 2004 05:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfMp-00060z-37 for idr@optimus.ietf.org; Fri, 27 Feb 2004 05:37:15 -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 FAA24916 for ; Fri, 27 Feb 2004 05:37:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwfMl-00028l-00 for idr@ietf.org; Fri, 27 Feb 2004 05:37:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwfLm-00022F-00 for idr@ietf.org; Fri, 27 Feb 2004 05:36:10 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AwfKm-0001rg-00 for idr@ietf.org; Fri, 27 Feb 2004 05:35:08 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1RAXa1m014444; Fri, 27 Feb 2004 02:33:36 -0800 (PST) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR89584; Fri, 27 Feb 2004 02:33:34 -0800 (PST) Message-ID: <403F1CFB.4070107@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: Pekka Savola CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 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.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, 27 Feb 2004 02:33:31 -0800 Pekka, The case I believe Pedro is describing is nicely documented in the following slide on pages 30 & 31: http://www.securite.org/presentations/secip/BHAMS2001-SecIP-v105-full.ppt Those are pretty common DDoS protection techniques for the lack of better and more granular tools to filter attacks yet deployed in the networks. It would be therefor not right to consider route as not resolvable if it resolves to "null" route on any BGP speaker. Cheers, R. > Pekka Savola wrote: > > On Thu, 26 Feb 2004, Pedro Roque Marques wrote: > >>> For the purposes of this check, the routes for which >>>packets are discarded by the router (i.e., "null" or "discard" >>>routes) SHOULD be considered unresolvable. >> >>That would break all the instances where people intentionally use a >>nexthop that resolves to a discard route to drop traffic. e.g. /32s >>that are advertised w/ a drop community. > > > I'm not really familiar with the different discard route propagation > techniques, so bear with me.. > > The BGP speaker receiving a prefix which points to discard address > would fail only if the discard nexthop was in the receiving BGP > speaker, correct? Otherwise, the router would not know it is a > discard route (even though it'll be discarded by some other box). > > That is, is BGP used to advertise routes, whose next-hop is a discard > address, to those BGP speakers which have configured the address as > discard? > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA02677 for ; Fri, 27 Feb 2004 02:49:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awck2-0003Hg-DQ; Fri, 27 Feb 2004 02:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcjD-0003Fz-6x for idr@optimus.ietf.org; Fri, 27 Feb 2004 02:48:11 -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 CAA19155 for ; Fri, 27 Feb 2004 02:48:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awcj9-0000WD-00 for idr@ietf.org; Fri, 27 Feb 2004 02:48:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwciG-0000Rh-00 for idr@ietf.org; Fri, 27 Feb 2004 02:47:12 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awci4-0000Ma-00 for idr@ietf.org; Fri, 27 Feb 2004 02:47:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1R7kTC06258; Fri, 27 Feb 2004 09:46:29 +0200 From: Pekka Savola To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200402270711.i1R7BLpp039800@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: Fri, 27 Feb 2004 09:46:29 +0200 (EET) On Thu, 26 Feb 2004, Pedro Roque Marques wrote: > > For the purposes of this check, the routes for which > > packets are discarded by the router (i.e., "null" or "discard" > > routes) SHOULD be considered unresolvable. > > That would break all the instances where people intentionally use a > nexthop that resolves to a discard route to drop traffic. e.g. /32s > that are advertised w/ a drop community. I'm not really familiar with the different discard route propagation techniques, so bear with me.. The BGP speaker receiving a prefix which points to discard address would fail only if the discard nexthop was in the receiving BGP speaker, correct? Otherwise, the router would not know it is a discard route (even though it'll be discarded by some other box). That is, is BGP used to advertise routes, whose next-hop is a discard address, to those BGP speakers which have configured the address as discard? -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA02377 for ; Fri, 27 Feb 2004 02:14:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcC9-0004J3-KX; Fri, 27 Feb 2004 02:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcBR-00041Q-Q4 for idr@optimus.ietf.org; Fri, 27 Feb 2004 02:13:17 -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 CAA16552 for ; Fri, 27 Feb 2004 02:13:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcBO-0004Ow-00 for idr@ietf.org; Fri, 27 Feb 2004 02:13:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcAV-0004JE-00 for idr@ietf.org; Fri, 27 Feb 2004 02:12:19 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AwcA2-0004Cv-00 for idr@ietf.org; Fri, 27 Feb 2004 02:11:50 -0500 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 i1R7BL1K039803; Thu, 26 Feb 2004 23:11:21 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i1R7BLpp039800; Thu, 26 Feb 2004 23:11:21 -0800 (PST) Message-Id: <200402270711.i1R7BLpp039800@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: idr@ietf.org Subject: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: References: 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: Thu, 26 Feb 2004 23:11:21 -0800 (PST) Pekka Savola writes: > I propose adding something like: > For the purposes of this check, the routes for which > packets are discarded by the router (i.e., "null" or "discard" > routes) SHOULD be considered unresolvable. That would break all the instances where people intentionally use a nexthop that resolves to a discard route to drop traffic. e.g. /32s that are advertised w/ a drop community. I don't believe this proposal is feasible. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA02262 for ; Fri, 27 Feb 2004 02:04:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awc2X-0000F6-Gb; Fri, 27 Feb 2004 02:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awc22-00004u-Ko for idr@optimus.ietf.org; Fri, 27 Feb 2004 02:03:34 -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 CAA07585 for ; Fri, 27 Feb 2004 02:03:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awc1z-0003EM-00 for idr@ietf.org; Fri, 27 Feb 2004 02:03:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awc1H-00036O-00 for idr@ietf.org; Fri, 27 Feb 2004 02:02:47 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awc0U-0002wv-00 for idr@ietf.org; Fri, 27 Feb 2004 02:01:58 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1R71SM05499 for ; Fri, 27 Feb 2004 09:01:29 +0200 From: Pekka Savola To: idr@ietf.org 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 Subject: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 27 Feb 2004 09:01:28 +0200 (EET) Hi, We analyzed one source of operational BGP problems and noticed a problem which should be made explicit in the BGP specification. In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1: 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the refer- enced interface is up and IP processing is enabled on this inter- face. I propose adding something like: For the purposes of this check, the routes for which packets are discarded by the router (i.e., "null" or "discard" routes) SHOULD be considered unresolvable. .. the problem is that unless you have full routing table in every router, and no default discard/aggregate routes/etc., this works. Otherwise when your IBGP neighbor goes down, the BGP routes learned from that neighbor stay in the BGP table until the BGP session is reset after 90 seconds or so. Instead, the routes should immediately be removed from BGP when the loopback address is removed from the IGP. I would argue even for stronger statement than SHOULD, but that would invalidate existing implementations. -- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA02151 for ; Fri, 27 Feb 2004 01:53:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awbrp-00070K-N6; Fri, 27 Feb 2004 01:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awbqy-0006yl-Fh for idr@optimus.ietf.org; Fri, 27 Feb 2004 01:52:08 -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 BAA03145 for ; Fri, 27 Feb 2004 01:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awbqv-00025Z-00 for idr@ietf.org; Fri, 27 Feb 2004 01:52:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awbpz-00021B-00 for idr@ietf.org; Fri, 27 Feb 2004 01:51:08 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Awbpg-0001wN-00 for idr@ietf.org; Fri, 27 Feb 2004 01:50:48 -0500 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 i1R6oB1K039750; Thu, 26 Feb 2004 22:50:11 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i1R6oBuU039747; Thu, 26 Feb 2004 22:50:11 -0800 (PST) Message-Id: <200402270650.i1R6oBuU039747@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: curtis@fictitious.org Cc: idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: <200402270525.i1R5PCRX031392@workhorse.fictitious.org> References: <200402270301.i1R31ueR039423@roque-bsd.juniper.net> <200402270525.i1R5PCRX031392@workhorse.fictitious.org> 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: Thu, 26 Feb 2004 22:50:11 -0800 (PST) Curtis Villamizar writes: > If withdraws propogate faster first the unfeasible AS paths are > removed, then the feasible ones start propogating. The result is > some withdraw followed by add but much less AS path change in the > presence of cycles. The point in which we differ is that you equate withdraws and updates w/ unfeasible and feasible paths. I don't believe one can make that assumption. For a given AS, if you have as input an withdraw that can result in an update being generated or vice-versa, depending on the policy. You can have a link up event result in withdrawns being generated, and a link down event result in updates. In other words the addition of feasible paths, can result via policy, in withdrawls. > Providing separate timers allows us to defer the question of which > is preferable. Providing separate timers, imho, will just further confuse the issue :-). It has already been showen that there is no single choice of MRAI timer that is appropriate for all situations. Now you propose an additional one. That is two parameters nobody knows what the optimal setting should be. Furthermore, i believe that, due to the meshed nature of internet connectivity, using different delays may increase the duration of transients. Lets say that you start w/ a current path through as3 and you have a link up event (a) that brings up a prefered path. as 3 | --a-> as 1 --> as 4 --a-> as 2 --> as 4 If a is a peer route for as 1 but a customer route for as 2, then by propagating the withdrawl faster you are increasing the transient time and causing increase connectivity to create a blackhole for as4. imho, currently there is only one good known value for MRAI for both updates and withdrawls, and that is 0. Let BGP speakers propagate updates as fast as they can, taking into account that BGP itself already has embedded flow control mechanisms that allow a receiver to pace a sender appropriatly. Unfortunatly, even that setting (0) has its drawbacks. One is that values should probably be consistent within an as, and there are very different interpretations of MRAI between different vendors. The second is that in case of MED oscillations, MRAI helps reduce the ammount of churn. regards, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA01501 for ; Fri, 27 Feb 2004 00:36:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwafJ-0001ZF-QD; Fri, 27 Feb 2004 00:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwaWl-0000wX-Vc for idr@optimus.ietf.org; Fri, 27 Feb 2004 00:27:12 -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 AAA00386 for ; Fri, 27 Feb 2004 00:27:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwaWj-0001sD-00 for idr@ietf.org; Fri, 27 Feb 2004 00:27:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwaVn-0001mH-00 for idr@ietf.org; Fri, 27 Feb 2004 00:26:12 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AwaVJ-0001ga-00 for idr@ietf.org; Fri, 27 Feb 2004 00:25:41 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1R5PCRX031392; Fri, 27 Feb 2004 00:25:13 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402270525.i1R5PCRX031392@workhorse.fictitious.org> To: Pedro Roque Marques cc: curtis@fictitious.org, idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Thu, 26 Feb 2004 19:01:56 PST." <200402270301.i1R31ueR039423@roque-bsd.juniper.net> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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: Fri, 27 Feb 2004 00:25:12 -0500 In message <200402270301.i1R31ueR039423@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > Curtis Villamizar writes: > > > > As a matter of best practice it seems to be accepted that the > > withdraw timer should be less than the advertise timer so withdraws > > propogate faster than AS path changes. Whether the withdraw timer > > has to be zero is an open question. > > I disagree w/ that conclusion... > > Take the following network diagram > > +--------+ > customer1 --- | as 1 | -- customer2 > | | | > | | | > peer1 --- | | -- peer2 > +--------+ > > > case 1) > assume customer1 advertises 10.0.1/24, that is also advertised to you > by peer1. > > An withrawn of the prefix because of failure of the ebgp session > between customer1 and as1 will result in: > - an update to customer2 w/ aspath "peer1 customer1". > - an withdrawl to peer2. An update to customer2 with a different AS path is a route change and would occur more slowly. The faster withdraw would mean that you'd tell customer2 you had no route, then tell customer2 the best router was through peer1. Where this matters is if there is a cycle: AS1 -- AS2 -- AS3 -- AS4 -- AS5 -- ASn -- back to AS1 with other AS connected to each of the AS in this cycle, perhaps forming other cycles. If AS3 announced a route and then withdrew it, about half way around the cycle a router would get a withdraw and advertise around the other way that it had a route from that direction. For example, if ASn preferred the route via AS5 then if AS1 withdrew its router, ASn would advertise the alternate. This gets real ugly when there are multiple cycles adjacent to each other as is the case in a well meshed set of AS such as the Internet. If withdraws propogate faster first the unfeasible AS paths are removed, then the feasible ones start propogating. The result is some withdraw followed by add but much less AS path change in the presence of cycles. > case 2) > Now assume that 10.0.1/24 path is only advertised by customer1 w/ > as-path "customer1 10 10 10" and that peer1 sends you an advertisement > w/ "peer1 10" for the same prefix. This will result in: > - an update to customer2 > - an withrawl to peer2. > > i.e. an update can be transformed in an withdrawl and vice-versa. > > imho, in BGP updates and withdrawls both constitute reachability > information, that although encoded in different ways should be > propagated acording to the same rules, in terms of delays. > > cheers, > Pedro. Providing separate timers allows us to defer the question of which is preferable. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA00221 for ; Thu, 26 Feb 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 1AwYJD-0001Gb-IS; Thu, 26 Feb 2004 22:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYIF-0001EH-VV for idr@optimus.ietf.org; Thu, 26 Feb 2004 22:04:04 -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 WAA25347 for ; Thu, 26 Feb 2004 22:04:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwYIC-0003BK-00 for idr@ietf.org; Thu, 26 Feb 2004 22:04:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwYHE-00036S-00 for idr@ietf.org; Thu, 26 Feb 2004 22:03:00 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AwYGo-000317-00 for idr@ietf.org; Thu, 26 Feb 2004 22:02:34 -0500 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 i1R31u1K039426; Thu, 26 Feb 2004 19:01:56 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i1R31ueR039423; Thu, 26 Feb 2004 19:01:56 -0800 (PST) Message-Id: <200402270301.i1R31ueR039423@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: curtis@fictitious.org Cc: idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: <200402250159.i1P1xbRX011106@workhorse.fictitious.org> References: <20040225001325.98735.qmail@web25210.mail.ukl.yahoo.com> <200402250159.i1P1xbRX011106@workhorse.fictitious.org> 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: Thu, 26 Feb 2004 19:01:56 -0800 (PST) Curtis Villamizar writes: > As a matter of best practice it seems to be accepted that the > withdraw timer should be less than the advertise timer so withdraws > propogate faster than AS path changes. Whether the withdraw timer > has to be zero is an open question. I disagree w/ that conclusion... Take the following network diagram +--------+ customer1 --- | as 1 | -- customer2 | | | | | | peer1 --- | | -- peer2 +--------+ case 1) assume customer1 advertises 10.0.1/24, that is also advertised to you by peer1. An withrawn of the prefix because of failure of the ebgp session between customer1 and as1 will result in: - an update to customer2 w/ aspath "peer1 customer1". - an withdrawl to peer2. case 2) Now assume that 10.0.1/24 path is only advertised by customer1 w/ as-path "customer1 10 10 10" and that peer1 sends you an advertisement w/ "peer1 10" for the same prefix. This will result in: - an update to customer2 - an withrawl to peer2. i.e. an update can be transformed in an withdrawl and vice-versa. imho, in BGP updates and withdrawls both constitute reachability information, that although encoded in different ways should be propagated acording to the same rules, in terms of delays. cheers, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA29137 for ; Thu, 26 Feb 2004 19:54:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWGP-0001ZK-K5; Thu, 26 Feb 2004 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvoMV-0000Jj-B3 for idr@optimus.ietf.org; Tue, 24 Feb 2004 21:01:23 -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 VAA22073 for ; Tue, 24 Feb 2004 21:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvoMS-0003Z8-00 for idr@ietf.org; Tue, 24 Feb 2004 21:01:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvoLX-0003VX-00 for idr@ietf.org; Tue, 24 Feb 2004 21:00:23 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AvoKo-0003Rj-00 for idr@ietf.org; Tue, 24 Feb 2004 20:59:38 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1P1xbRX011106; Tue, 24 Feb 2004 20:59:37 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402250159.i1P1xbRX011106@workhorse.fictitious.org> To: BGP Guru cc: Jeffrey Haas , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Wed, 25 Feb 2004 00:13:25 GMT." <20040225001325.98735.qmail@web25210.mail.ukl.yahoo.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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, 24 Feb 2004 20:59:37 -0500 In message <20040225001325.98735.qmail@web25210.mail.ukl.yahoo.com>, BGP Guru w rites: > --- Jeffrey Haas wrote: > > On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru > > wrote: > > > Could anyone please clarify why we need two timers > > for > > > Route-Advertisement? > > > > Originating your own routes is governed by the MAOI > > timer. > > Propagating someone else's routes is governed by the > > MRAI timer. > > > > This also made me look for something which appears > > to not be there > > any longer. > > > > Draft -17 and before had unfeasible NLRI propagate > > immediately. > > Draft -18 and later changed this to have unfeasable > > nlri governed > > by the timers. > > > > I thought Craig and Abha had determined this was a > > Bad Thing? > > > > I do not think that holding back route-withdrawals by > timer intervals is a "bad thing" at all. I suppose > that this opinion is due to the thought that there > might be black-holing of data traffic. But if you > consider the "big picture" of entire network, one can > vividly see how beneficial this really is. A simple > example would be, if one enters a CLI command which is > implemented to reset a peering session, and that peer > has announced a million prefixes, it would definitely > not be wise to withdraw all those prefixes from the > other 500 peers because the peering will anyways be > back within say 15-20sec or so. This would save us > from sending a millions of withdrawals and > re-advertising millions again because of a temporary > glitch. Infact there may not be any data being > black-holed at all. Im totally for keeping this the > way draft-18 and later suggest. Regardless of what Craig and Abha thought was best for the Internet, routers exist which allow a configurable withdraw timer. It is possible to set the timer to zero if the timer is implemented. It is not possible to set it non-zero if it is not implemented. Whatever the setting, there are no interoperability problems but failing to withdraw a route can cause loss of traffic for the duration of the timer. As a matter of best practice it seems to be accepted that the withdraw timer should be less than the advertise timer so withdraws propogate faster than AS path changes. Whether the withdraw timer has to be zero is an open question. This leads to a problem in the draft. There is one MRAI timer in the draft that applies to either withdraw or advertise. Withdraws should be fast and advertisements can be slower. There should at least be two timers specified. IMHO - Implementations MUST support an advertise timer. Implementations MAY send withdraws immediately but SHOULD support a separate withdraw timer. Implementations MAY use the advertise timer with withdraws but SHOULD keep the two timers separate. No one has argued (to my knowledge) that the originate and advertise timers should not be implemented. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA29138 for ; Thu, 26 Feb 2004 19:54:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwWGP-0001ZC-23; Thu, 26 Feb 2004 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avo29-0007sY-P5 for idr@optimus.ietf.org; Tue, 24 Feb 2004 20:40:21 -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 UAA21476 for ; Tue, 24 Feb 2004 20:40:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avo27-0001rh-00 for idr@ietf.org; Tue, 24 Feb 2004 20:40:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avo19-0001nP-00 for idr@ietf.org; Tue, 24 Feb 2004 20:39:20 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Avo0I-0001jB-00 for idr@ietf.org; Tue, 24 Feb 2004 20:38:26 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1P1cFRX010990; Tue, 24 Feb 2004 20:38:15 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402250138.i1P1cFRX010990@workhorse.fictitious.org> To: BGP Guru cc: Jeffrey Haas , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Tue, 24 Feb 2004 23:52:23 GMT." <20040224235223.76661.qmail@web25205.mail.ukl.yahoo.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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, 24 Feb 2004 20:38:15 -0500 In message <20040224235223.76661.qmail@web25205.mail.ukl.yahoo.com>, BGP Guru w rites: > Jeff, > > Thanks for your response. I have a further query on > this: > > > Originating your own routes is governed by the MAOI > > timer. > > What does "own" here refer to? Does "own" refer to > 'Local Router/Box' or does it refer to 'Local AS'. And > if it is 'Local AS' how can we segregate > advertisements received from IBGP peers which are > generated by the IBGP peers themselves and those that > are originated from outside our AS and advertised by > IBGP peer? > > > Propagating someone else's routes is governed by the > > MRAI timer. > > > > As continuation of the above query, "someone else's" - > does it refer to other IBGP peers or those originating > strictly from outside the AS? And how is the > distinction supposed to be made? > > Thanks, > > Guru Lets start with the table of contents. Note the presence of a section entitled "Originating BGP routes". Find that section. Read the one paragraph. It contains a definition of "Originating BGP routes". It means distilling stuff from your own AS and sending it to other routers. Now find "Routes: Advertisement and Storage" in the table of contents. It has 4 paragraphs, three of which are one or two sentences. A brief definitition of route advertisement is there and it is clear from the definitions and from usage in the document that it means passing a route to other BGP speakers. Just to shed some light on common practices, if a route is learned from the IGP you wouldn't send it to IBGP peers. If it is local (ie: direct connected) and not advertised into the IGP then you could use IBGP. If it was local and also advertised into the IGP you wouldn't normally advertise into IBGP unless you had some special need like you wanted to attach BGP communities to it. In the section "Frequency of Route Advertisement" it says: the procedure describe in this section SHOULD NOT apply for routes sent to internal peers. So there is part of your answer for IBGP. Look at the one paragraph in "Frequency of Route Origination" and the one paragraph in "Originating BGP routes" in it should be clear what "originating" means and that there is a timer on that operation. So when you "originate" a route you send it to everyone except as restricted by configured policy. You apply the MAOI for originating and when that is satisfied you can send to everyone at once unless further constrained by the MRAI timer. The MRAI doesn't apply to IBGP so it could only apply to your EBGP peerings. Note that if other routers in the IGP are using the same MRAI setting (configured the same) a locally originated route should leave the AS from all peerings (where configured policy allows) at about the same time. If they are not configured with the same timer either the operator had a reason or the operator messed up. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24937 for ; Thu, 26 Feb 2004 11:15:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOAA-0001RF-SZ; Thu, 26 Feb 2004 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwO9n-0001QS-Er for idr@optimus.ietf.org; Thu, 26 Feb 2004 11:14:40 -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 LAA22440 for ; Thu, 26 Feb 2004 11:14:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwO9m-0004K8-00 for idr@ietf.org; Thu, 26 Feb 2004 11:14:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwO8x-0004FH-00 for idr@ietf.org; Thu, 26 Feb 2004 11:13:48 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AwO8A-00043X-00 for idr@ietf.org; Thu, 26 Feb 2004 11:12:58 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 188192D48D7; Thu, 26 Feb 2004 11:12:19 -0500 (EST) 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 36605-01-9; Thu, 26 Feb 2004 11:12:17 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7673E2D48A7; Thu, 26 Feb 2004 11:12:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm Thread-Index: AcP8g0bL8zOEtyBdRJy540UwFEOJ2w== 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] Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 26 Feb 2004 11:12:06 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA24937 Agenda for IDR 1) Document status [5 minutes] 2) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Sue Hares 3) BGP Peer Restart Backoff Mechanisms [10 minutes] Sue Hares document: draft-hares-bgp-backoff-02.txt Author: Susan Hares 4) Deterministic Route Redistribution into BGP [10 minutes] Enke Chen document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen 5) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Sue Hares Wei Lou 6) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt (ietf) (-01 on web site) Author: Susan Hares 7) Charter Discussion [20 minutes] Thanks to all implementors who send in reports on the the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA24027 for ; Thu, 26 Feb 2004 09:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMgF-0001lL-R9; Thu, 26 Feb 2004 09:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMfl-0001eL-D3 for idr@optimus.ietf.org; Thu, 26 Feb 2004 09:39:33 -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 JAA15735 for ; Thu, 26 Feb 2004 09:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMfj-0000Re-00 for idr@ietf.org; Thu, 26 Feb 2004 09:39:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMel-0000Mf-00 for idr@ietf.org; Thu, 26 Feb 2004 09:38:31 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AwMdl-0000EA-00 for idr@ietf.org; Thu, 26 Feb 2004 09:37:29 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F010B2D4818; Thu, 26 Feb 2004 09:36:58 -0500 (EST) 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 34339-01-3; Thu, 26 Feb 2004 09:36:58 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F23532D480C; Thu, 26 Feb 2004 09:36:57 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i1QEav509804; Thu, 26 Feb 2004 09:36:57 -0500 (EST) From: Jeffrey Haas To: curtis@fictitious.org Cc: idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer Message-ID: <20040226093657.A4496@nexthop.com> References: <20040225001325.98735.qmail@web25210.mail.ukl.yahoo.com> <200402250159.i1P1xbRX011106@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200402250159.i1P1xbRX011106@workhorse.fictitious.org>; from curtis@workhorse.fictitious.org on Tue, Feb 24, 2004 at 08:59:37PM -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: Thu, 26 Feb 2004 09:36:57 -0500 On Tue, Feb 24, 2004 at 08:59:37PM -0500, Curtis Villamizar wrote: > As a matter of best practice it seems to be accepted that the withdraw > timer should be less than the advertise timer so withdraws propogate > faster than AS path changes. Right. You immediately point out the problem we now have from the current draft: > This leads to a problem in the draft. There is one MRAI timer in the > draft that applies to either withdraw or advertise. Withdraws should > be fast and advertisements can be slower. There should at least be > two timers specified. Similarly, MAOI may need something similar, although one can argue that since this is the originating AS as opposed to a transit AS that the issue is much less severe. Unfortunately, we're rather far into last call and this will probably not be addressed. We're probably to the point where someone should probably do a draft that contains known issues with BGP. :-) > No one has argued (to my knowledge) that the originate and advertise > timers should not be implemented. Although some would argue that these timers have been poorly implemented and we have relied on WRD in it's place. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA02385 for ; Tue, 24 Feb 2004 19:16:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvmiY-0002gE-Pw; Tue, 24 Feb 2004 19:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avmi5-0002dV-OV for idr@optimus.ietf.org; Tue, 24 Feb 2004 19:15:33 -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 TAA18578 for ; Tue, 24 Feb 2004 19:15:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avmi4-0002X0-00 for idr@ietf.org; Tue, 24 Feb 2004 19:15:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvmhF-0002PT-00 for idr@ietf.org; Tue, 24 Feb 2004 19:14:41 -0500 Received: from web25210.mail.ukl.yahoo.com ([217.12.10.70]) by ietf-mx with smtp (Exim 4.12) id 1AvmgW-0002El-00 for idr@ietf.org; Tue, 24 Feb 2004 19:13:56 -0500 Message-ID: <20040225001325.98735.qmail@web25210.mail.ukl.yahoo.com> Received: from [65.223.109.2] by web25210.mail.ukl.yahoo.com via HTTP; Wed, 25 Feb 2004 00:13:25 GMT From: =?iso-8859-1?q?BGP=20Guru?= Subject: Re: [Idr] Question on MinASOrig Timer To: Jeffrey Haas Cc: idr@ietf.org In-Reply-To: <20040223092449.A6672@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 25 Feb 2004 00:13:25 +0000 (GMT) --- Jeffrey Haas wrote: > On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru > wrote: > > Could anyone please clarify why we need two timers > for > > Route-Advertisement? > > Originating your own routes is governed by the MAOI > timer. > Propagating someone else's routes is governed by the > MRAI timer. > > This also made me look for something which appears > to not be there > any longer. > > Draft -17 and before had unfeasible NLRI propagate > immediately. > Draft -18 and later changed this to have unfeasable > nlri governed > by the timers. > > I thought Craig and Abha had determined this was a > Bad Thing? > I do not think that holding back route-withdrawals by timer intervals is a "bad thing" at all. I suppose that this opinion is due to the thought that there might be black-holing of data traffic. But if you consider the "big picture" of entire network, one can vividly see how beneficial this really is. A simple example would be, if one enters a CLI command which is implemented to reset a peering session, and that peer has announced a million prefixes, it would definitely not be wise to withdraw all those prefixes from the other 500 peers because the peering will anyways be back within say 15-20sec or so. This would save us from sending a millions of withdrawals and re-advertising millions again because of a temporary glitch. Infact there may not be any data being black-holed at all. Im totally for keeping this the way draft-18 and later suggest. > -- > Jeff Haas > NextHop Technologies > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA02132 for ; Tue, 24 Feb 2004 18:55: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 1AvmOF-0001EH-8n; Tue, 24 Feb 2004 18:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvmNg-00019S-OJ for idr@optimus.ietf.org; Tue, 24 Feb 2004 18:54: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 SAA17793 for ; Tue, 24 Feb 2004 18:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvmNd-0000ft-00 for idr@ietf.org; Tue, 24 Feb 2004 18:54:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvmMj-0000an-00 for idr@ietf.org; Tue, 24 Feb 2004 18:53:29 -0500 Received: from web25205.mail.ukl.yahoo.com ([217.12.10.65]) by ietf-mx with smtp (Exim 4.12) id 1AvmMB-0000V8-00 for idr@ietf.org; Tue, 24 Feb 2004 18:52:55 -0500 Message-ID: <20040224235223.76661.qmail@web25205.mail.ukl.yahoo.com> Received: from [65.223.109.2] by web25205.mail.ukl.yahoo.com via HTTP; Tue, 24 Feb 2004 23:52:23 GMT From: =?iso-8859-1?q?BGP=20Guru?= Subject: Re: [Idr] Question on MinASOrig Timer To: Jeffrey Haas Cc: idr@ietf.org In-Reply-To: <20040223092449.A6672@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 24 Feb 2004 23:52:23 +0000 (GMT) Jeff, Thanks for your response. I have a further query on this: > Originating your own routes is governed by the MAOI > timer. What does "own" here refer to? Does "own" refer to 'Local Router/Box' or does it refer to 'Local AS'. And if it is 'Local AS' how can we segregate advertisements received from IBGP peers which are generated by the IBGP peers themselves and those that are originated from outside our AS and advertised by IBGP peer? > Propagating someone else's routes is governed by the > MRAI timer. > As continuation of the above query, "someone else's" - does it refer to other IBGP peers or those originating strictly from outside the AS? And how is the distinction supposed to be made? Thanks, Guru --- Jeffrey Haas wrote: > On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru > wrote: > > Could anyone please clarify why we need two timers > for > > Route-Advertisement? > > Originating your own routes is governed by the MAOI > timer. > Propagating someone else's routes is governed by the > MRAI timer. > > This also made me look for something which appears > to not be there > any longer. > > Draft -17 and before had unfeasible NLRI propagate > immediately. > Draft -18 and later changed this to have unfeasable > nlri governed > by the timers. > > I thought Craig and Abha had determined this was a > Bad Thing? > > -- > Jeff Haas > NextHop Technologies > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12347 for ; Mon, 23 Feb 2004 12:26:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJqD-0000oK-Tt; Mon, 23 Feb 2004 12:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJpW-0000ma-4L for idr@optimus.ietf.org; Mon, 23 Feb 2004 12:25:18 -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 MAA07420 for ; Mon, 23 Feb 2004 12:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJpU-0007ao-00 for idr@ietf.org; Mon, 23 Feb 2004 12:25:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJoW-0007SS-00 for idr@ietf.org; Mon, 23 Feb 2004 12:24:16 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AvJnW-0007Hw-00 for idr@ietf.org; Mon, 23 Feb 2004 12:23:15 -0500 Received: from [192.168.0.2] (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i1NHMcDm004046; Mon, 23 Feb 2004 11:22:38 -0600 (CST) From: Andrew Lange To: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] issue with text in 9.1.4 Message-ID: <341882210.1077528157@[192.168.0.2]> In-Reply-To: <200402222013.i1MKDoo57389@merlot.juniper.net> References: <200402222013.i1MKDoo57389@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, 23 Feb 2004 09:22:37 -0800 I would prefer the second option (reword the text) for two reasons: 1) The implementation report does not cover all implementations, so the aggregation behavior can still be present in the field. 2) Since both methods of Loc-RIB installation would result in the same forwarding behavior to outside routers, we shouldn't preclude vendors from implementing route aggregation if they choose. Andrew --On Sunday, February 22, 2004 12:13 PM -0800 Yakov Rekhter wrote: > Folks, > > From 9.1.4: > > If a BGP speaker receives overlapping routes, the Decision Process > MUST consider both routes based on the configured acceptance policy. > If both a less and a more specific route are accepted, then the Deci- > sion Process MUST either install in Loc-RIB both the less and the > more specific routes or it MUST aggregate the two routes and install > in Loc-RIB the aggregated route, provided that both routes have the > same value of the NEXT_HOP attribute. > > The problem with the above text is that based on the information > provided by the vendors who participated in the implementation > survey we do not have enough implementations that implement what > is specified in the second part of the last sentence above ("it > MUST aggregate the two routes and install in Loc-RIB the aggregated > route, provided that both routes have the same value of the NEXT_HOP > attribute"). > > There are (at least) two ways to address this: > > Option 1: remove the second part of the sentence. The resulting text > will be as follows: > > If a BGP speaker receives overlapping routes, the Decision Process > MUST consider both routes based on the configured acceptance policy. > If both a less and a more specific route are accepted, then the Deci- > sion Process MUST install in Loc-RIB both the less and the > more specific routes. > > Option 2: reword the sentence. The resulting text will be as follows: > > If a BGP speaker receives overlapping routes, the Decision Process > MUST consider both routes based on the configured acceptance policy. > If both a less and a more specific route are accepted, then the Deci- > sion Process MUST install in Loc-RIB either both the less and the > more specific routes or aggregate the two routes and install > in Loc-RIB the aggregated route, provided that both routes have the > same value of the NEXT_HOP attribute. > > Please let me know if you have any preferences (or you have some > other option to suggest). > > Yakov. > > _______________________________________________ > 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA10856 for ; Mon, 23 Feb 2004 10:11:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHja-0004Au-KZ; Mon, 23 Feb 2004 10:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8XW-00069o-A3 for idr@optimus.ietf.org; Mon, 23 Feb 2004 00:21:58 -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 AAA24262 for ; Mon, 23 Feb 2004 00:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av8XT-0000tO-00 for idr@ietf.org; Mon, 23 Feb 2004 00:21:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av8WZ-0000qu-00 for idr@ietf.org; Mon, 23 Feb 2004 00:21:00 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1Av8W2-0000nh-00 for idr@ietf.org; Mon, 23 Feb 2004 00:20:26 -0500 Received: (qmail 38691 invoked from network); 23 Feb 2004 05:19:56 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 23 Feb 2004 05:19:56 -0000 In-Reply-To: <20040223045804.58763.qmail@web25201.mail.ukl.yahoo.com> References: <20040223045804.58763.qmail@web25201.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] Question on MinASOrig Timer To: BGP Guru X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 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: Sun, 22 Feb 2004 21:19:59 -0800 Sorry, misread the question. Disregard my response. On Feb 22, 2004, at 8:58 PM, BGP Guru wrote: > > > Section 9.2.1.2 of BGP draft-23 states: > > 9.2.1.2 Frequency of Route Origination > > The parameter MinASOriginationIntervalTimer > determines the minimum amount of time that must > elapse between successive advertisements of > UPDATE messages that report changes within the > advertising BGP speaker's own autonomous systems. > > Could anyone please clarify why we need two timers for > Route-Advertisement? There is already > "MinRouteAdvertisementInterval" which limits the > frequency of generation of UPDATEs. I donot understand > the role of "MinSASOriginationInterval" timer. How are > these two timers serving different purposes? > > > > > > > > ___________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > > _______________________________________________ > 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA10370 for ; Mon, 23 Feb 2004 09:28:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvH4K-0004nk-7A; Mon, 23 Feb 2004 09:28:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvH3E-0004lH-CJ for idr@optimus.ietf.org; Mon, 23 Feb 2004 09:27:16 -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 JAA27512 for ; Mon, 23 Feb 2004 09:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvH3C-0007Lq-00 for idr@ietf.org; Mon, 23 Feb 2004 09:27:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvH2M-0007Ej-00 for idr@ietf.org; Mon, 23 Feb 2004 09:26:22 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AvH1M-00071w-00 for idr@ietf.org; Mon, 23 Feb 2004 09:25:20 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 898302D495D; Mon, 23 Feb 2004 09:24:50 -0500 (EST) 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 56519-01-5; Mon, 23 Feb 2004 09:24:49 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8A41A2D495C; Mon, 23 Feb 2004 09:24:49 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i1NEOnZ06712; Mon, 23 Feb 2004 09:24:49 -0500 (EST) From: Jeffrey Haas To: BGP Guru Cc: idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer Message-ID: <20040223092449.A6672@nexthop.com> References: <20040223045804.58763.qmail@web25201.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040223045804.58763.qmail@web25201.mail.ukl.yahoo.com>; from bgp_acharya@yahoo.co.uk on Mon, Feb 23, 2004 at 04:58:04AM +0000 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.1 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, 23 Feb 2004 09:24:49 -0500 On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru wrote: > Could anyone please clarify why we need two timers for > Route-Advertisement? Originating your own routes is governed by the MAOI timer. Propagating someone else's routes is governed by the MRAI timer. This also made me look for something which appears to not be there any longer. Draft -17 and before had unfeasible NLRI propagate immediately. Draft -18 and later changed this to have unfeasable nlri governed by the timers. I thought Craig and Abha had determined this was a Bad Thing? -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA04412 for ; Mon, 23 Feb 2004 00:01:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8DF-000550-7N; Mon, 23 Feb 2004 00:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8CM-0004y7-OR for idr@optimus.ietf.org; Mon, 23 Feb 2004 00:00:06 -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 AAA23774 for ; Mon, 23 Feb 2004 00:00:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av8CK-0007Pt-00 for idr@ietf.org; Mon, 23 Feb 2004 00:00:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av8Ba-0007Lb-00 for idr@ietf.org; Sun, 22 Feb 2004 23:59:18 -0500 Received: from web25201.mail.ukl.yahoo.com ([217.12.10.61]) by ietf-mx with smtp (Exim 4.12) id 1Av8As-0007CY-00 for idr@ietf.org; Sun, 22 Feb 2004 23:58:34 -0500 Message-ID: <20040223045804.58763.qmail@web25201.mail.ukl.yahoo.com> Received: from [65.223.109.2] by web25201.mail.ukl.yahoo.com via HTTP; Mon, 23 Feb 2004 04:58:04 GMT From: =?iso-8859-1?q?BGP=20Guru?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [Idr] Question on MinASOrig Timer Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 23 Feb 2004 04:58:04 +0000 (GMT) Section 9.2.1.2 of BGP draft-23 states: 9.2.1.2 Frequency of Route Origination The parameter MinASOriginationIntervalTimer determines the minimum amount of time that must elapse between successive advertisements of UPDATE messages that report changes within the advertising BGP speaker's own autonomous systems. Could anyone please clarify why we need two timers for Route-Advertisement? There is already "MinRouteAdvertisementInterval" which limits the frequency of generation of UPDATEs. I donot understand the role of "MinSASOriginationInterval" timer. How are these two timers serving different purposes? ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA29221 for ; Sun, 22 Feb 2004 15:16: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 1Av01C-0003Mr-1K; Sun, 22 Feb 2004 15:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av00s-0003Hj-30 for idr@optimus.ietf.org; Sun, 22 Feb 2004 15:15:42 -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 PAA07137 for ; Sun, 22 Feb 2004 15:15:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av00q-0006yo-00 for idr@ietf.org; Sun, 22 Feb 2004 15:15:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av003-0006wL-00 for idr@ietf.org; Sun, 22 Feb 2004 15:14:52 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1Auzzd-0006t0-00 for idr@ietf.org; Sun, 22 Feb 2004 15:14:25 -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 i1MKDtl54372 for ; Sun, 22 Feb 2004 12:13:55 -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 i1MKDoo57389 for ; Sun, 22 Feb 2004 12:13:50 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402222013.i1MKDoo57389@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11621.1077480830.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=none autolearn=no version=2.60 Subject: [Idr] issue with text in 9.1.4 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 22 Feb 2004 12:13:50 -0800 Folks, >From 9.1.4: If a BGP speaker receives overlapping routes, the Decision Process MUST consider both routes based on the configured acceptance policy. If both a less and a more specific route are accepted, then the Deci- sion Process MUST either install in Loc-RIB both the less and the more specific routes or it MUST aggregate the two routes and install in Loc-RIB the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute. The problem with the above text is that based on the information provided by the vendors who participated in the implementation survey we do not have enough implementations that implement what is specified in the second part of the last sentence above ("it MUST aggregate the two routes and install in Loc-RIB the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute"). There are (at least) two ways to address this: Option 1: remove the second part of the sentence. The resulting text will be as follows: If a BGP speaker receives overlapping routes, the Decision Process MUST consider both routes based on the configured acceptance policy. If both a less and a more specific route are accepted, then the Deci- sion Process MUST install in Loc-RIB both the less and the more specific routes. Option 2: reword the sentence. The resulting text will be as follows: If a BGP speaker receives overlapping routes, the Decision Process MUST consider both routes based on the configured acceptance policy. If both a less and a more specific route are accepted, then the Deci- sion Process MUST install in Loc-RIB either both the less and the more specific routes or aggregate the two routes and install in Loc-RIB the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute. Please let me know if you have any preferences (or you have some other option to suggest). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA29046 for ; Sun, 22 Feb 2004 14:59: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 1Auzkj-00026b-0w; Sun, 22 Feb 2004 14:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuzkQ-00026H-GR for idr@optimus.ietf.org; Sun, 22 Feb 2004 14:58:42 -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 OAA05777 for ; Sun, 22 Feb 2004 14:58:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuzkN-0005tL-00 for idr@ietf.org; Sun, 22 Feb 2004 14:58:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auzjg-0005qQ-00 for idr@ietf.org; Sun, 22 Feb 2004 14:57:56 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AuzjA-0005mc-00 for idr@ietf.org; Sun, 22 Feb 2004 14:57:25 -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 i1MJusl54335 for ; Sun, 22 Feb 2004 11:56:54 -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 i1MJuno56516 for ; Sun, 22 Feb 2004 11:56:49 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402221956.i1MJuno56516@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10238.1077479809.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=none autolearn=no version=2.60 Subject: [Idr] (non-normative) text in Appendix F Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 22 Feb 2004 11:56:49 -0800 Folks, Since Appendix F deals with implementation *recommendations* it should not have any normative text. Therefore I'd like to replace all normative "SHOULD", "MUST", etc... with non-normative "should", "must", etc... Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04958 for ; Thu, 12 Feb 2004 15:31:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNUF-0001je-0j; Thu, 12 Feb 2004 15:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNTb-0001ZW-BQ for idr@optimus.ietf.org; Thu, 12 Feb 2004 15:30:23 -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 PAA13005 for ; Thu, 12 Feb 2004 15:30:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNTY-00008I-00 for idr@ietf.org; Thu, 12 Feb 2004 15:30:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNSY-00001u-00 for idr@ietf.org; Thu, 12 Feb 2004 15:29:19 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1ArNRa-0007ga-00 for idr@ietf.org; Thu, 12 Feb 2004 15:28:18 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9F1BE2D4951; Thu, 12 Feb 2004 15:27:50 -0500 (EST) 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 11121-01-37; Thu, 12 Feb 2004 15:27:49 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id ADDA12D4945; Thu, 12 Feb 2004 15:27:49 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i1CKRmG11216; Thu, 12 Feb 2004 15:27:48 -0500 (EST) From: Jeffrey Haas To: Sharon Chisholm , "Wayne F. Tackabury" Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp4-mibv2-04.txt General Review Comments Message-ID: <20040212152748.C9742@nexthop.com> References: <3549C09B853DD5119B540002A52CDD340A2438C5@zcard0ka.ca.norte l.com> <5.1.0.14.0.20040211140727.03a80008@mail.goldwiretech.com> <3549C09B853DD5119B540002A52CDD340A2438C5@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2438C5@zcard0ka.ca.nortel.com>; from schishol@nortelnetworks.com on Wed, Feb 11, 2004 at 12:03:19PM -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.1 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, 12 Feb 2004 15:27:48 -0500 On Wed, Feb 11, 2004 at 12:03:19PM -0500, Sharon Chisholm wrote: > 1. I think much of the discussion around extensibility should be revisited, This is one of the things I intended to do some cleanout during my next break to work on the MIB. The feedback is good though. > 2. The organization of objects is somewhat unusual, especially when it comes > to Notifications and Conformance. See Appendix D of the MIB review > guidelines for the recommended design pattern. Conformance is definitely one item that has suffered throughout the MIBs since the texts I've had available to me to explain them were less than complete on that area. I think the v1MIB has educated me enough to make a better attempt on the v2MIB in the next release. This last issue was simply to get the v2MIB back in circulation since it had expired and yet integrate some of the known changes. As for the MIB layout, this is definitely doable and will mostly require adding another level of hierarchy in the objects portion of the MIB. This is yet another case where I shouldn't have trusted the original BGP MIB as a guideline for organization. > 3. The MIB is fairly large and from my understanding there is still a lot > more stuff that will likely go in it. I think it might be worthwhile to ask > ourselves two questions to ensure we are on the right track with respect to > what we need to define > A. Do we really expect people to configure BGP using SNMP, or can > get away with a monitoring MIB, plus potentially some read-write objects for > status and other forms of non-row-creating read-write objects? A slightly better question is even if we *do* want configuration to be part of the MIB, should it go in this document, or should we define a separate document for the configuration? In previous discussions, Wayne and I had decided that the monolithic document was probably the best option until the general structure of the MIB was reasonably well set and then we could re-address the issue. > B. Are we reporting what we should be reporting or simply what can be > reported? This has been one of the items of contention. The base v1MIB provides access to the "BGP routing table", more specifically the Ribs. As BGP has evolved, the stuff that is stored in this abstract database has expanded and is the one item that is likely to continue expanding with the protocol. If we delete the ability to retrieve the RIBs from the MIB, the vast majority of the readable objects from the MIB disappear. If we keep this in, we should provide the ability to get to as much information as possible. It can be easily argued (and has been by many parties) that SNMP is simply The Wrong Tool for getting at the routing table. However, until we have consensus, we can't get rid of it. > 4. There are a number parts of the document that read more like wg charter > discussion or editor's note. These need to eventually be replaced with text > that assumes that the audience of the document is people who are looking at > implementing the MIB. Much of the administrative text is in need of updating. Wayne did a wonderful job in the initial versions and we can now update it. On Wed, Feb 11, 2004 at 02:21:19PM -0500, Wayne F. Tackabury wrote: > work on it a lot back then :), thanks for the attention. You've done a > great job of articulating issues that I've been aware are hanging out there > and I'm surprised we haven't had to confront yet. That's what we get when we push on one version of the MIB at a time. :-) At this point I don't believe I'll have the opportunity to issue a -05 prior to IETF, but will issue one soon thereafter. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA23713 for ; Wed, 11 Feb 2004 19:04:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Km-0004rD-T2; Wed, 11 Feb 2004 19:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF4q-0007ey-H0 for idr@optimus.ietf.org; Mon, 09 Feb 2004 12:20:08 -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 MAA28887 for ; Mon, 9 Feb 2004 12:20:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF4p-0003Oy-00 for idr@ietf.org; Mon, 09 Feb 2004 12:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF3q-0003JE-00 for idr@ietf.org; Mon, 09 Feb 2004 12:19:06 -0500 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 1AqF2s-0003CR-00 for idr@ietf.org; Mon, 09 Feb 2004 12:18:06 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19HI6s74944 for ; Mon, 9 Feb 2004 12:18:06 -0500 (EST) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19HI5E81500 for ; Mon, 9 Feb 2004 12:18:05 -0500 (EST) Received: from ericsson.com (rasna.torrentnet.com [4.21.152.29]) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id i19HI5o20924 for ; Mon, 9 Feb 2004 12:18:05 -0500 (EST) Message-ID: <4027C0CD.5030303@ericsson.com> From: "Sanjay S. Rao" Reply-To: sanjayr@torrentnet.com Organization: Ericsson IPI User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org References: <011601c3dc11$75062e80$8404060a@future.futsoft.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 Subject: [Idr] Graceful Restart question Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 09 Feb 2004 12:18:05 -0500 Hi, I have a question regarding "Graceful Restart" for BGP (http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt): In section 7.1 the draft says: "To put an upper bound on the amount of time a router defers its route selection, an implementation MUST support a (configurable) timer that imposes this upper bound." What is the recommendation if that "configurable timer" time-out. Should the connection with the peer be closed or should the route selection begin as if end of RIB marker was received from all the peers ? Is it recommended to put this same upper bound when waiting for End of RIB marker even for normal connection establishment (not restarting or receiving speakers' case). Thanks Sanjay S. Rao -- Sanjay S. Rao Protocols Group Ericsson IP Infrastructure Rockville, MD ======================================================================== Phone 240-314-3611 eMail sanjay.rao@ericsson.com _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA23716 for ; Wed, 11 Feb 2004 19:04:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Ko-0004re-Nw; Wed, 11 Feb 2004 19:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1KB-000473-NI for idr@optimus.ietf.org; Wed, 11 Feb 2004 15:51:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22513; Wed, 11 Feb 2004 15:51:09 -0500 (EST) Message-Id: <200402112051.PAA22513@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-mibagent-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, 11 Feb 2004 15:51:08 -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 : BGP MIB V1 implementation survey Author(s) : S. Hares Filename : draft-ietf-idr-bgp-mibagent-survey-00.txt Pages : 38 Date : 2004-2-11 This document provides of survey of BGP-4 RFC 1657 MIB agent implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-mibagent-survey-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-bgp-mibagent-survey-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-2-11160448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-mibagent-survey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11160448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA23715 for ; Wed, 11 Feb 2004 19:04:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Kn-0004rL-F3; Wed, 11 Feb 2004 19:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJY7-0008Fn-9B for idr@optimus.ietf.org; Mon, 09 Feb 2004 17:06:39 -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 RAA20420 for ; Mon, 9 Feb 2004 17:06:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJY5-00045N-00 for idr@ietf.org; Mon, 09 Feb 2004 17:06:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJWy-0003qv-00 for idr@ietf.org; Mon, 09 Feb 2004 17:05:28 -0500 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 1AqJVR-0003WQ-00 for idr@ietf.org; Mon, 09 Feb 2004 17:03:53 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19M3r191701 for ; Mon, 9 Feb 2004 17:03:53 -0500 (EST) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19M3rL04479 for ; Mon, 9 Feb 2004 17:03:53 -0500 (EST) Received: from ericsson.com (rasna.torrentnet.com [4.21.152.29]) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id i19M3qI03799 for ; Mon, 9 Feb 2004 17:03:52 -0500 (EST) Message-ID: <402803C8.2010804@ericsson.com> From: "Sanjay S. Rao" Reply-To: sanjayr@torrentnet.com Organization: Ericsson IPI User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr 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 Subject: [Idr] Graceful Restart question Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 09 Feb 2004 17:03:52 -0500 Hi, I have a question regarding "Graceful Restart" for BGP (http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt): In section 7.1 the draft says: "To put an upper bound on the amount of time a router defers its route selection, an implementation MUST support a (configurable) timer that imposes this upper bound." What is the recommendation if that "configurable timer" time-out. Should the connection with the peer be closed or should the route selection begin as if end of RIB marker was received from all the peers ? Is it recommended to put this same upper bound when waiting for End of RIB marker even for normal connection establishment (not restarting or receiving speakers' case). Thanks Sanjay S. Rao -- Sanjay S. Rao Protocols Group Ericsson IP Infrastructure ======================================================================== Phone 240-314-3611 eMail sanjay.rao@ericsson.com _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA23714 for ; Wed, 11 Feb 2004 19:04:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Ko-0004rT-4Q; Wed, 11 Feb 2004 19:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqbnq-0000x7-RA for idr@optimus.ietf.org; Tue, 10 Feb 2004 12:36:06 -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 MAA28888 for ; Tue, 10 Feb 2004 12:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqbnp-00019x-00 for idr@ietf.org; Tue, 10 Feb 2004 12:36:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqbmH-0000oO-00 for idr@ietf.org; Tue, 10 Feb 2004 12:34:30 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AqblN-0000eS-00 for idr@ietf.org; Tue, 10 Feb 2004 12:33:33 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1AHVKRX098044; Tue, 10 Feb 2004 12:31:20 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402101731.i1AHVKRX098044@workhorse.fictitious.org> To: Enke Chen cc: idr@ietf.org, jenny@redback.com Reply-To: curtis@fictitious.org Subject: Re: [Idr] draft-chen-bgp-redist-00.txt In-reply-to: Your message of "Mon, 09 Feb 2004 14:21:43 PST." <20040209222143.29BEA15D3C2@popserv1.redback.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 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, 10 Feb 2004 12:31:20 -0500 In message <20040209222143.29BEA15D3C2@popserv1.redback.com>, Enke Chen writes: > Hi, folks: > Here is a new draft that was just posted. Please let us know > if you have any comments. > > Thanks. -- Enke Enke, There is one problem with this. There is no such thing as admin distance in the BGP spec itself or in any routing protocol. This just seems to be a feature that (almost?) everyone has implemented but has no protocol spec. Do we need a base spec for this that defines what admin distance is? [If there is such a thing, then never mind.] Maybe you could rename this draft so that "Administrative Distance" was part of the title and you define what it is and how it is used (which is essentially done in intro, though being very brief), including the rule you've proposed. Curtis > ------- Forwarded Message > > Message-Id: <200402092109.QAA12121@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-bgp-redist-00.txt > Date: Mon, 09 Feb 2004 16:09:07 -0500 > > - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directorie > s. > > > Title : Deterministic Route Redistribution into BGP > Author(s) : E. Chen > Filename : draft-chen-bgp-redist-00.txt > Pages : 5 > Date : 2004-2-9 > > In this document we propose an enhancement to the BGP route selection > algorithm that would make the interaction of redistributed routes and > other BGP routes deterministic, thus facilitating the deployment of > various routing requirements. The proposed enhancement is backward > compatible. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-bgp-redist-00.txt > > ------- 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 (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20692 for ; Wed, 11 Feb 2004 14:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzyo-0004Xf-K8; Wed, 11 Feb 2004 14:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzyi-0004Wl-Ib for idr@optimus.ietf.org; Wed, 11 Feb 2004 14:24:56 -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 OAA15944 for ; Wed, 11 Feb 2004 14:24:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzyf-0002Aw-00 for idr@ietf.org; Wed, 11 Feb 2004 14:24:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzxr-00025O-00 for idr@ietf.org; Wed, 11 Feb 2004 14:24:04 -0500 Received: from bond.goldwiretech.com ([63.150.239.226]) by ietf-mx with esmtp (Exim 4.12) id 1AqzxQ-0001yw-00 for idr@ietf.org; Wed, 11 Feb 2004 14:23:36 -0500 Received: from qtip.goldwiretech.com (qtip [10.0.0.150]) by bond.goldwiretech.com (8.12.8/8.12.8) with ESMTP id i1BJNaar010753 for ; Wed, 11 Feb 2004 14:23:36 -0500 Message-Id: <5.1.0.14.0.20040211140727.03a80008@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: idr@ietf.org From: "Wayne F. Tackabury" Subject: Re: [Idr] draft-ietf-idr-bgp4-mibv2-04.txt General Review Comments In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2438C5@zcard0ka.ca.norte l.com> Mime-Version: 1.0 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=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, 11 Feb 2004 14:21:19 -0500 Sharon: As someone who hasn't worked on the document in over two years but sure did work on it a lot back then :), thanks for the attention. You've done a great job of articulating issues that I've been aware are hanging out there and I'm surprised we haven't had to confront yet. At 12:03 PM 2/11/2004 -0500, Sharon Chisholm wrote: > A. Do we really expect people to configure BGP using SNMP, or can >get away with a monitoring MIB, plus potentially some read-write objects for >status and other forms of non-row-creating read-write objects? That was certainly an explicit goal at the time we started this effort. Lacking this objective, to be honest, I wonder if much of the justification for an complete new "BGP MIB Version" melts away, as opposed to simply a RFC 1657 ++ extensibility mechanism. As for my take, my own views on the importance of MIB configuration capabilities and its being essential to even the continued relevance of SNMP has been published elsewhere and I won't take it up here. :) > B. Are we reporting what we should be reporting or simply what can be >reported? There's a filter of operational relevance that Jeff and I have been hoping will be applied in the wg discussion of the MIB. >5. There are a number of points in the document where things are being >explained where it is not clear to me whether the document is meant to be >explaining basically how SNMP & MIBs work, or is trying to describe >something else. To cover this and your last point, when this was first published, a number of MIB documents were taking hits inside and outside of the IETF community for being impossibly abstract and lacking sufficient background and *particularly* usage examples to be useful by nonacademic operational personnel. Jeff and I were getting a lot of input to be very broad in the level of introductory material necessary to illustrate intended usage. Much like the sheer number of monitoring objects, to be candid, we intentionally overdid it to see just how far we overdid it. Now, I'm all for segregating boilerplate and intro as opposed to specific discussion, but just keep the original intent in mind before throwing out the baby with the bathwater, as it were. I've been lurking a bit here, but your comments were thoughtful enough that I just wanted to provide these few points of historical illustration in response. Regards, Wayne _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16643 for ; Wed, 11 Feb 2004 12:06: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 1AqxoH-0000u1-S3; Wed, 11 Feb 2004 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqxo2-0000qp-Vi for idr@optimus.ietf.org; Wed, 11 Feb 2004 12:05:46 -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 MAA09644 for ; Wed, 11 Feb 2004 12:05:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqxo1-0002xz-00 for idr@ietf.org; Wed, 11 Feb 2004 12:05:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqxn7-0002rk-00 for idr@ietf.org; Wed, 11 Feb 2004 12:04:49 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AqxmG-0002g0-00 for idr@ietf.org; Wed, 11 Feb 2004 12:03:56 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BH3On14309 for ; Wed, 11 Feb 2004 12:03:24 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH71LX>; Wed, 11 Feb 2004 12:03:24 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2438C5@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org 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=AWL autolearn=no version=2.60 Subject: [Idr] draft-ietf-idr-bgp4-mibv2-04.txt General Review Comments Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 11 Feb 2004 12:03:19 -0500 Hi I usually just send my more obscure review comments to directly to Jeff, but I thought some of these might benefit from a bit of discussion so I'm sending them to the list. MIB boilerplate, review guidelines and other resources can be found on the OPS page http://www.ops.ietf.org/ 1. I think much of the discussion around extensibility should be revisited, potentially for the method that is being used, but certainly for how it is explained. I think part of the problem is some ambiguity in the discussion between MIB extensions and BPG protocol extensions. It should be clear that they are independent concepts as well as it needs to be clear at any given time which is being discussed. It's fine to define a relationship or working method between the two, but first they need to be understood independently. In general I would say there are three types of MIB extensibility A. Updating a MIB B. Updating a textual convention in IANA C. Defining a new MIB that defines an extension It seems like this draft is doing A by the fact that it is defining objects for the various BGP extensions that have come along, but there is discussion about B & C although it's not clear to me what exactly is being done in this ID to support those. There is discussion about basing the OID value of future protocol extensions objects on the on RFC number of the protocol extension, but my understanding was that this idea was scraped, a decision I agree with. 2. The organization of objects is somewhat unusual, especially when it comes to Notifications and Conformance. See Appendix D of the MIB review guidelines for the recommended design pattern. 3. The MIB is fairly large and from my understanding there is still a lot more stuff that will likely go in it. I think it might be worthwhile to ask ourselves two questions to ensure we are on the right track with respect to what we need to define A. Do we really expect people to configure BGP using SNMP, or can get away with a monitoring MIB, plus potentially some read-write objects for status and other forms of non-row-creating read-write objects? B. Are we reporting what we should be reporting or simply what can be reported? 4. There are a number parts of the document that read more like wg charter discussion or editor's note. These need to eventually be replaced with text that assumes that the audience of the document is people who are looking at implementing the MIB. 5. There are a number of points in the document where things are being explained where it is not clear to me whether the document is meant to be explaining basically how SNMP & MIBs work, or is trying to describe something else. To make this more obvious, I would suggest letting the MIB boilerplate explain the basics of SNMP and then assume this in the rest of the discussion. If you feel it adds value to explain some generic SNMP and MIB aspect, perhaps including reference to the SNMP specification will make it clear that is what you are doing or otherwise make it clear that you are not inventing something new in the MIB. Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA03942 for ; Tue, 10 Feb 2004 16:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfTD-0000b0-Ra; Tue, 10 Feb 2004 16:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfT1-0000Zn-AL for idr@optimus.ietf.org; Tue, 10 Feb 2004 16:30:51 -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 QAA18912 for ; Tue, 10 Feb 2004 16:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfSz-0005uQ-00 for idr@ietf.org; Tue, 10 Feb 2004 16:30:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfR3-0005Pv-00 for idr@ietf.org; Tue, 10 Feb 2004 16:28:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqfOd-0004tD-00 for idr@ietf.org; Tue, 10 Feb 2004 16:26:19 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqf9K-0002Lh-PA for idr@ietf.org; Tue, 10 Feb 2004 16:10:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqf9D-0001pM-Bk; Tue, 10 Feb 2004 21:10:23 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <160335053201.20040210130958@psg.com> To: Enke Chen CC: curtis@fictitious.org, idr@ietf.org, jenny@redback.com Subject: Re: [Idr] draft-chen-bgp-redist-00.txt In-Reply-To: <20040210201101.71FD215D3C2@popserv1.redback.com> References: <20040210201101.71FD215D3C2@popserv1.redback.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.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO 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, 10 Feb 2004 13:09:58 -0800 Enke, Curtis- >> Enke, >> >> There is one problem with this. There is no such thing as admin >> distance in the BGP spec itself or in any routing protocol. This just >> seems to be a feature that (almost?) everyone has implemented but has >> no protocol spec. Do we need a base spec for this that defines what >> admin distance is? [If there is such a thing, then never mind.] >> >> Maybe you could rename this draft so that "Administrative Distance" >> was part of the title and you define what it is and how it is used >> (which is essentially done in intro, though being very brief), >> including the rule you've proposed. > Thanks for these suggestions. We will re-title the draft, and expand > on the "admin distance" in the next revision. Regarding the admin distance, RFC 1812 (Router Reqs) talks about ranking routing info sources and a priority mechanism for choosing routes from different routing processes in section 7. One could build on top of this if needed. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03175 for ; Tue, 10 Feb 2004 15:14: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 1AqeGg-0006VM-Ge; Tue, 10 Feb 2004 15:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeFl-0006BB-BP for idr@optimus.ietf.org; Tue, 10 Feb 2004 15:13:05 -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 PAA07368 for ; Tue, 10 Feb 2004 15:13:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeFj-0002um-00 for idr@ietf.org; Tue, 10 Feb 2004 15:13:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeEn-0002lP-00 for idr@ietf.org; Tue, 10 Feb 2004 15:12:06 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AqeDp-0002c2-00 for idr@ietf.org; Tue, 10 Feb 2004 15:11:05 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C7A8440D447; Tue, 10 Feb 2004 12:11:04 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18175-08; Tue, 10 Feb 2004 12:11:04 -0800 (PST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 1729340D442; Tue, 10 Feb 2004 12:11:03 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 71FD215D3C2; Tue, 10 Feb 2004 12:11:01 -0800 (PST) To: curtis@fictitious.org Cc: idr@ietf.org, jenny@redback.com, enke@redback.com Subject: Re: [Idr] draft-chen-bgp-redist-00.txt In-Reply-To: Message from Curtis Villamizar of "Tue, 10 Feb 2004 12:31:20 EST." <200402101731.i1AHVKRX098044@workhorse.fictitious.org> From: Enke Chen Message-Id: <20040210201101.71FD215D3C2@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=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, 10 Feb 2004 12:11:01 -0800 Hi, Curtis: > Message-Id: <200402101731.i1AHVKRX098044@workhorse.fictitious.org> > To: Enke Chen > Cc: idr@ietf.org, jenny@redback.com > Reply-To: curtis@fictitious.org > Subject: Re: [Idr] draft-chen-bgp-redist-00.txt > In-reply-to: Your message of "Mon, 09 Feb 2004 14:21:43 PST." > <20040209222143.29BEA15D3C2@popserv1.redback.com> > Date: Tue, 10 Feb 2004 12:31:20 -0500 > From: Curtis Villamizar > > > In message <20040209222143.29BEA15D3C2@popserv1.redback.com>, Enke Chen writes: > > Hi, folks: > > Here is a new draft that was just posted. Please let us know > > if you have any comments. > > > > Thanks. -- Enke > > > > Enke, > > There is one problem with this. There is no such thing as admin > distance in the BGP spec itself or in any routing protocol. This just > seems to be a feature that (almost?) everyone has implemented but has > no protocol spec. Do we need a base spec for this that defines what > admin distance is? [If there is such a thing, then never mind.] > > Maybe you could rename this draft so that "Administrative Distance" > was part of the title and you define what it is and how it is used > (which is essentially done in intro, though being very brief), > including the rule you've proposed. Thanks for these suggestions. We will re-title the draft, and expand on the "admin distance" in the next revision. -- Enke > > Curtis > > > > > ------- Forwarded Message > > > > Message-Id: <200402092109.QAA12121@ietf.org> > > To: IETF-Announce: ; > > From: Internet-Drafts@ietf.org > > Reply-To: Internet-Drafts@ietf.org > > Subject: I-D ACTION:draft-chen-bgp-redist-00.txt > > Date: Mon, 09 Feb 2004 16:09:07 -0500 > > > > - --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts directorie > > s. > > > > > > Title : Deterministic Route Redistribution into BGP > > Author(s) : E. Chen > > Filename : draft-chen-bgp-redist-00.txt > > Pages : 5 > > Date : 2004-2-9 > > > > In this document we propose an enhancement to the BGP route selection > > algorithm that would make the interaction of redistributed routes and > > other BGP routes deterministic, thus facilitating the deployment of > > various routing requirements. The proposed enhancement is backward > > compatible. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chen-bgp-redist-00.txt > > > > ------- End of Forwarded Message > > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA29417 for ; Tue, 10 Feb 2004 09:22:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYm1-00060u-Ov; Tue, 10 Feb 2004 09:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYl6-000602-Ia for idr@optimus.ietf.org; Tue, 10 Feb 2004 09:21:04 -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 JAA19418 for ; Tue, 10 Feb 2004 09:21:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYl4-0004b2-00 for idr@ietf.org; Tue, 10 Feb 2004 09:21:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYkH-0004VG-00 for idr@ietf.org; Tue, 10 Feb 2004 09:20:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AqYjP-0004LV-00 for idr@ietf.org; Tue, 10 Feb 2004 09:19:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2004 06:19:17 -0800 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 i1AEIkuA001989; Tue, 10 Feb 2004 06:18:46 -0800 (PST) Received: from [192.35.166.223] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA16766; Tue, 10 Feb 2004 09:18:44 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <40280541.2060201@torrentnet.com> References: <40280541.2060201@torrentnet.com> To: sanjayr@torrentnet.com From: "John G. Scudder" Subject: Re: [Idr] Graceful Restart question .. Cc: idr 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=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, 10 Feb 2004 09:17:39 -0500 At 5:10 PM -0500 2/9/04, Sanjay S. Rao wrote: >What is the recommendation if that "configurable timer" time-out. >Should the connection with the peer be closed or should the route >selection begin as if end of RIB marker was received from all the >peers ? The latter. >Is it recommended to put this same upper bound when waiting for End >of RIB marker even for normal connection >establishment (not restarting or receiving speakers' case). Some upper bound, in any case. We can add a small clarification to these in a future revision. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA19334 for ; Mon, 9 Feb 2004 17:24:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJov-0001OZ-Ir; Mon, 09 Feb 2004 17:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJob-0001Nj-Mp for idr@optimus.ietf.org; Mon, 09 Feb 2004 17:23:41 -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 RAA22828 for ; Mon, 9 Feb 2004 17:23:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJoZ-00072r-00 for idr@ietf.org; Mon, 09 Feb 2004 17:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJne-0006qc-00 for idr@ietf.org; Mon, 09 Feb 2004 17:22:43 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AqJmq-0006fe-00 for idr@ietf.org; Mon, 09 Feb 2004 17:21:52 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D87338C7B46; Mon, 9 Feb 2004 14:21:43 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04269-06; Mon, 9 Feb 2004 14:21:43 -0800 (PST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 8791A8C7B40; Mon, 9 Feb 2004 14:21:43 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 29BEA15D3C2; Mon, 9 Feb 2004 14:21:43 -0800 (PST) To: idr@ietf.org Cc: enke@redback.com, jenny@redback.com From: Enke Chen Message-Id: <20040209222143.29BEA15D3C2@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=none autolearn=no version=2.60 Subject: [Idr] draft-chen-bgp-redist-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, 09 Feb 2004 14:21:43 -0800 Hi, folks: Here is a new draft that was just posted. Please let us know if you have any comments. Thanks. -- Enke ------- Forwarded Message Message-Id: <200402092109.QAA12121@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-redist-00.txt Date: Mon, 09 Feb 2004 16:09:07 -0500 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Deterministic Route Redistribution into BGP Author(s) : E. Chen Filename : draft-chen-bgp-redist-00.txt Pages : 5 Date : 2004-2-9 In this document we propose an enhancement to the BGP route selection algorithm that would make the interaction of redistributed routes and other BGP routes deterministic, thus facilitating the deployment of various routing requirements. The proposed enhancement is backward compatible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-redist-00.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA19299 for ; Mon, 9 Feb 2004 17:12:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJdJ-0000aK-GB; Mon, 09 Feb 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJd1-0000Zs-Ln for idr@optimus.ietf.org; Mon, 09 Feb 2004 17:11:43 -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 RAA21224 for ; Mon, 9 Feb 2004 17:11:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJcz-00050C-00 for idr@ietf.org; Mon, 09 Feb 2004 17:11:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJcH-0004sw-00 for idr@ietf.org; Mon, 09 Feb 2004 17:10:58 -0500 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 1AqJbW-0004iu-00 for idr@ietf.org; Mon, 09 Feb 2004 17:10:10 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19MAAC92074 for ; Mon, 9 Feb 2004 17:10:10 -0500 (EST) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i19MA9504874 for ; Mon, 9 Feb 2004 17:10:09 -0500 (EST) Received: from torrentnet.com (rasna.torrentnet.com [4.21.152.29]) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id i19MA9Y04065 for ; Mon, 9 Feb 2004 17:10:09 -0500 (EST) Message-ID: <40280541.2060201@torrentnet.com> From: "Sanjay S. Rao" Reply-To: sanjayr@torrentnet.com Organization: Ericsson IPI User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr 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 Subject: [Idr] Graceful Restart question .. Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 09 Feb 2004 17:10:09 -0500 Hi, I have a question regarding "Graceful Restart" for BGP (http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt): In section 7.1 the draft says: "To put an upper bound on the amount of time a router defers its route selection, an implementation MUST support a (configurable) timer that imposes this upper bound." What is the recommendation if that "configurable timer" time-out. Should the connection with the peer be closed or should the route selection begin as if end of RIB marker was received from all the peers ? Is it recommended to put this same upper bound when waiting for End of RIB marker even for normal connection establishment (not restarting or receiving speakers' case). Thanks Sanjay S. Rao -- Sanjay S. Rao Protocols Group Ericsson IP Infrastructure ======================================================================== Phone 240-314-3611 eMail sanjay.rao@ericsson.com _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA08416 for ; Sat, 7 Feb 2004 00:50:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApLLv-00060s-En; Sat, 07 Feb 2004 00:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApLL9-0005dX-6v for idr@optimus.ietf.org; Sat, 07 Feb 2004 00:49:15 -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 AAA09673 for ; Sat, 7 Feb 2004 00:49:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApLL6-0004fh-00 for idr@ietf.org; Sat, 07 Feb 2004 00:49:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApLK7-0004bZ-00 for idr@ietf.org; Sat, 07 Feb 2004 00:48:11 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ApLJh-0004Z6-00 for idr@ietf.org; Sat, 07 Feb 2004 00:47:45 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ApLJf-000IoF-Bp; Sat, 07 Feb 2004 05:47:43 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <11220104248.20040206214049@psg.com> To: David Meyer CC: kireeti@juniper.net, idr@ietf.org In-Reply-To: <20040206214140.GA17441@1-4-5.net> References: <200402061607.i16G7aMg010671@m106.maoz.com> <45176836066.20040206112406@psg.com> <20040206214140.GA17441@1-4-5.net> 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.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: problem with the allocation policy Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 6 Feb 2004 21:40:49 -0800 Dave, >>> Do you mean what initiates the IANA action or whether the IANA >>> need to perform any checks before doing that? > Well, I guess it says that the WG chair will instruct the > IANA to make the allocation, i.e., the IANA doesn't have > any responsibility other than to maintain the > registry (but see below; what part of the regsitry do we > (IETF) have to replicate to make this work?) Correct. >>> The idea is that the IANA simply performs what's requested by >>> the chairs and/or authors (with AD approval) who keep track >>> of when allocations need to be deprecated and dealloacted. > Does this mean that we will be keeping our own registry > consisting of the various allocations, their owners, the > relevant WG chairs, and the timeouts? IANA already maintains status and the document name for each entry. If we add a timestamp, would it be enough data? Thanks, Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA03532 for ; Fri, 6 Feb 2004 16:48:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDpQ-0001zR-IS; Fri, 06 Feb 2004 16:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDoU-0001vS-6y for idr@optimus.ietf.org; Fri, 06 Feb 2004 16:47:02 -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 QAA22458 for ; Fri, 6 Feb 2004 16:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDoS-0003L9-00 for idr@ietf.org; Fri, 06 Feb 2004 16:47:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDmR-0002tw-00 for idr@ietf.org; Fri, 06 Feb 2004 16:44:57 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1ApDjm-0002EH-00 for idr@ietf.org; Fri, 06 Feb 2004 16:42:11 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i16Lfe3K017476; Fri, 6 Feb 2004 13:41:40 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i16Lfels017475; Fri, 6 Feb 2004 13:41:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f From: David Meyer To: Alex Zinin Cc: kireeti@juniper.net, idr@ietf.org Message-ID: <20040206214140.GA17441@1-4-5.net> References: <200402061607.i16G7aMg010671@m106.maoz.com> <45176836066.20040206112406@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45176836066.20040206112406@psg.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc 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 Subject: [Idr] Re: problem with the allocation policy Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 6 Feb 2004 13:41:40 -0800 On Fri, Feb 06, 2004 at 11:24:06AM -0800, Alex Zinin wrote: >> Dave, >> >> >> >> > Folks, >> >> > While I understand the need for such a policy (that much >> > seems to have been demonstrated), I have a few comments >> > on this draft: >> >> > (i). Request (Section 3.1) >> >> > Section 3.1 outlines a sequence of actions that >> > result in "temporary" IANA allocation. A couple >> > of points here. First, there seems to be a step >> > missing between action 4) and 5): >> >> >>> 4) If so, with the approval of the Area Director(s), the WG chairs >> >>> request IANA to make an early allocation. >> >>> >> >>> 5) IANA makes an allocation from the appropriate registry, marking it >> >>> as "temporary", valid for a period of one year from the date of >> >>> allocation. >> >> > namely, how does the IANA decide that it SHOULD >> > make the allocation? 4) talks about making a >> > request, 5) instructs the IANA to make the >> > allocation. That is, what criteria does the IANA >> > use to execute step 5)? >> >> Do you mean what initiates the IANA action or whether the IANA >> need to perform any checks before doing that? Well, I guess it says that the WG chair will instruct the IANA to make the allocation, i.e., the IANA doesn't have any responsibility other than to maintain the registry (but see below; what part of the regsitry do we (IETF) have to replicate to make this work?) >> Initiation of action would be an e-mail from the WG chairs, then >> Ack'ed by the ADs (e.g., as we do for WG milestone updates) >> >> As for the checks, I would expect IANA to verify conditions 2.a, >> and 2.b (simply existence of the documentation and a confirmation >> from the WG chair, again Ack'ed by ADs, that it's adequate), plus >> confirmation from the chairs that conditions c and d are met. Gotcha. >> >> > The second issue here is whether the IANA can >> > actually time out an allocation (i.e., do they >> > really have a notion of "temporary"; even though >> > section 3.3 states that the don't need to; who >> > does, and how to the revoke the allocation, >> > etc). >> >> Section 3.3 has this para that talks about it: >> >> If a follow-up request is not made, or the document fails to progress >> to a Standards Track RFC, the WG chairs are responsible for informing >> IANA that the code points are to be marked "deprecated" (and are not >> to be allocated); the WG chairs are further responsible for informing >> IANA when the deprecated code points can be completely de-allocated >> (i.e., made available for new allocations). >> >> > The reason I as is that in my role as IANA >> > technical adviser for multicast address >> > assignment, we have the option to make >> > allocations temporary (see RFC 3171), but the >> > IANA can't really execute against that (that is, >> > is seems they have no way of timing anything out; >> > even if that mechanism existed, it doesn't seem >> > that they have the next step, namely, a way to >> > recover the allocation). I suppose this is a >> > long-winded way of saying the "temporary tag" >> > seems (in my experience with the IANA) at best >> > operationally hypothetical. >> >> The idea is that the IANA simply performs what's requested by >> the chairs and/or authors (with AD approval) who keep track >> of when allocations need to be deprecated and dealloacted. Does this mean that we will be keeping our own registry consisting of the various allocations, their owners, the relevant WG chairs, and the timeouts? >> > (ii). One weakness with the RFC 2434 subject matter >> > expert approach is that more and more, people >> > just don't care (that is, if you have an >> > application that you can get to enough people >> > that uses some code point that should be IANA >> > assigned, e.g., a port or something), what do you >> > care about what the IANA says (they can't stop >> > you from using it, and if it gets into enough >> > code, well, you get the point; suffice it to say >> > that this happens). >> >> > In any event, the "pre-RFC deadlock" described >> > below seems to be just the case which will lead >> > to commercial interests overcoming the >> > process(es) you are trying to put in place, and >> > you'll wind up with either the situation >> > described above ("who cares what the IANA says"), >> > or a land-grab for spaces of interest (knowing >> > that the IANA can't really time out the >> > allocations). >> >> The way I look at it is IANA provides us with the function that we >> (the community) need. If folks don't care about IANA or don't >> understand it's needed, no amount of process can help here. On the >> other hand, poor process(es) may discourage use of IANA, which I think >> is the case with the "Standards Action" policy together with the STD >> requirements in RTG area. The latter is part of what I think is causing the behavior I described (although in the cases I've seen, I don't think any amount of process effeciency would have helped, sadly). >> Do you think that the processes proposed in the draft a) don't help >> the problem at all, b) make it worse, c) create a new one, d) >> something else? >> >> > (iii). Section 2 d) is too vague >> >> > "There is sufficient interest in early (pre-RFC) >> > implementation and deployment in the community." >> >> > e.g., how is "sufficient" defined (or for that matter, >> > what is a "community")? So my concern here is >> > that this section is too loosely worded, and as >> > such will open up the IANA to all kinds of early >> > allocation requests. For example, if/when this >> > becomes BCP, will it be possible to claim >> > "sufficient interest" (whatever that is) and use >> > that to circumvent "normal" allocation >> > procedures (noting that the IANA will not be >> > able to evaluate what constitutes "sufficient >> > interest"). >> >> You are absolutely right--whether interest is sufficient or not is a >> judgement call, just like the notion of a rough consensus. >> >> >> > (iv). Section 3.2. (Follow-up) >> >> > This seems to be granting WG chairs the authority >> > to revoke a prior early allocation? >> >> Right, based on the info from/discussion in the WG. >> >> > "It is the responsibility of the document authors >> > and the Working Group chairs to review changes in >> > the document, and especially in the >> > specifications of the code points for which early >> > allocation was requested to ensure that the >> > changes are backwards compatible." >> >> > Further, this section seems to create the >> > mechanism for someone to cause some code point to >> > be deprecated (just aruge that a change is >> > required but not backwards compatiable). >> >> The assumption is that by the time a temporary allocation is done, >> condition 2.c has been met and major changes to the technology are >> not required. Of course, it's a judgement call again, and there >> will be mistakes, and situations where we do need to make changes >> and they may as well be not backwards compatible. In this case, >> using the old typecode may be risky. Gotcha. Thanks, Dave _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02042 for ; Fri, 6 Feb 2004 14:27:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBd0-0005Kn-VX; Fri, 06 Feb 2004 14:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBc3-0005JH-ID for idr@optimus.ietf.org; Fri, 06 Feb 2004 14:26:03 -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 OAA11038 for ; Fri, 6 Feb 2004 14:26:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBc0-0005LO-00 for idr@ietf.org; Fri, 06 Feb 2004 14:26:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBb4-0005I8-00 for idr@ietf.org; Fri, 06 Feb 2004 14:25:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ApBab-0005ER-00 for idr@ietf.org; Fri, 06 Feb 2004 14:24:33 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ApBaa-0004NO-Au; Fri, 06 Feb 2004 19:24:32 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <45176836066.20040206112406@psg.com> To: David Meyer CC: kireeti@juniper.net, idr@ietf.org In-Reply-To: <200402061607.i16G7aMg010671@m106.maoz.com> References: <200402061607.i16G7aMg010671@m106.maoz.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.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: problem with the allocation policy Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 6 Feb 2004 11:24:06 -0800 Dave, > Folks, > While I understand the need for such a policy (that much > seems to have been demonstrated), I have a few comments > on this draft: > (i). Request (Section 3.1) > Section 3.1 outlines a sequence of actions that > result in "temporary" IANA allocation. A couple > of points here. First, there seems to be a step > missing between action 4) and 5): >>> 4) If so, with the approval of the Area Director(s), the WG chairs >>> request IANA to make an early allocation. >>> >>> 5) IANA makes an allocation from the appropriate registry, marking it >>> as "temporary", valid for a period of one year from the date of >>> allocation. > namely, how does the IANA decide that it SHOULD > make the allocation? 4) talks about making a > request, 5) instructs the IANA to make the > allocation. That is, what criteria does the IANA > use to execute step 5)? Do you mean what initiates the IANA action or whether the IANA need to perform any checks before doing that? Initiation of action would be an e-mail from the WG chairs, then Ack'ed by the ADs (e.g., as we do for WG milestone updates) As for the checks, I would expect IANA to verify conditions 2.a, and 2.b (simply existence of the documentation and a confirmation from the WG chair, again Ack'ed by ADs, that it's adequate), plus confirmation from the chairs that conditions c and d are met. > The second issue here is whether the IANA can > actually time out an allocation (i.e., do they > really have a notion of "temporary"; even though > section 3.3 states that the don't need to; who > does, and how to the revoke the allocation, > etc). Section 3.3 has this para that talks about it: If a follow-up request is not made, or the document fails to progress to a Standards Track RFC, the WG chairs are responsible for informing IANA that the code points are to be marked "deprecated" (and are not to be allocated); the WG chairs are further responsible for informing IANA when the deprecated code points can be completely de-allocated (i.e., made available for new allocations). > The reason I as is that in my role as IANA > technical adviser for multicast address > assignment, we have the option to make > allocations temporary (see RFC 3171), but the > IANA can't really execute against that (that is, > is seems they have no way of timing anything out; > even if that mechanism existed, it doesn't seem > that they have the next step, namely, a way to > recover the allocation). I suppose this is a > long-winded way of saying the "temporary tag" > seems (in my experience with the IANA) at best > operationally hypothetical. The idea is that the IANA simply performs what's requested by the chairs and/or authors (with AD approval) who keep track of when allocations need to be deprecated and dealloacted. > (ii). One weakness with the RFC 2434 subject matter > expert approach is that more and more, people > just don't care (that is, if you have an > application that you can get to enough people > that uses some code point that should be IANA > assigned, e.g., a port or something), what do you > care about what the IANA says (they can't stop > you from using it, and if it gets into enough > code, well, you get the point; suffice it to say > that this happens). > In any event, the "pre-RFC deadlock" described > below seems to be just the case which will lead > to commercial interests overcoming the > process(es) you are trying to put in place, and > you'll wind up with either the situation > described above ("who cares what the IANA says"), > or a land-grab for spaces of interest (knowing > that the IANA can't really time out the > allocations). The way I look at it is IANA provides us with the function that we (the community) need. If folks don't care about IANA or don't understand it's needed, no amount of process can help here. On the other hand, poor process(es) may discourage use of IANA, which I think is the case with the "Standards Action" policy together with the STD requirements in RTG area. Do you think that the processes proposed in the draft a) don't help the problem at all, b) make it worse, c) create a new one, d) something else? > (iii). Section 2 d) is too vague > "There is sufficient interest in early (pre-RFC) > implementation and deployment in the community." > e.g., how is "sufficient" defined (or for that matter, > what is a "community")? So my concern here is > that this section is too loosely worded, and as > such will open up the IANA to all kinds of early > allocation requests. For example, if/when this > becomes BCP, will it be possible to claim > "sufficient interest" (whatever that is) and use > that to circumvent "normal" allocation > procedures (noting that the IANA will not be > able to evaluate what constitutes "sufficient > interest"). You are absolutely right--whether interest is sufficient or not is a judgement call, just like the notion of a rough consensus. > (iv). Section 3.2. (Follow-up) > This seems to be granting WG chairs the authority > to revoke a prior early allocation? Right, based on the info from/discussion in the WG. > "It is the responsibility of the document authors > and the Working Group chairs to review changes in > the document, and especially in the > specifications of the code points for which early > allocation was requested to ensure that the > changes are backwards compatible." > Further, this section seems to create the > mechanism for someone to cause some code point to > be deprecated (just aruge that a change is > required but not backwards compatiable). The assumption is that by the time a temporary allocation is done, condition 2.c has been met and major changes to the technology are not required. Of course, it's a judgement call again, and there will be mistakes, and situations where we do need to make changes and they may as well be not backwards compatible. In this case, using the old typecode may be risky. > Just a couple of observations. Thanks, Dave. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00068 for ; Fri, 6 Feb 2004 11:10: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 1Ap8YM-0005pp-7b; Fri, 06 Feb 2004 11:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8YB-0005pM-40 for idr@optimus.ietf.org; Fri, 06 Feb 2004 11:09:51 -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 LAA02633 for ; Fri, 6 Feb 2004 11:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8Y8-00074D-00 for idr@ietf.org; Fri, 06 Feb 2004 11:09:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8XG-00071o-00 for idr@ietf.org; Fri, 06 Feb 2004 11:08:55 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8WU-0006xB-00 for idr@ietf.org; Fri, 06 Feb 2004 11:08:06 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i16G7a3K010674; Fri, 6 Feb 2004 08:07:36 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i16G7aMg010671; Fri, 6 Feb 2004 08:07:36 -0800 Message-Id: <200402061607.i16G7aMg010671@m106.maoz.com> From: David Meyer To: kireeti@juniper.net, zinin@psg.com cc: idr@ietf.org X-Spam-Checker-Version: SpamAssassin 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: problem with the allocation policy Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 6 Feb 2004 08:07:36 -0800 Folks, While I understand the need for such a policy (that much seems to have been demonstrated), I have a few comments on this draft: (i). Request (Section 3.1) Section 3.1 outlines a sequence of actions that result in "temporary" IANA allocation. A couple of points here. First, there seems to be a step missing between action 4) and 5): >> 4) If so, with the approval of the Area Director(s), the WG chairs >> request IANA to make an early allocation. >> >> 5) IANA makes an allocation from the appropriate registry, marking it >> as "temporary", valid for a period of one year from the date of >> allocation. namely, how does the IANA decide that it SHOULD make the allocation? 4) talks about making a request, 5) instructs the IANA to make the allocation. That is, what criteria does the IANA use to execute step 5)? The second issue here is whether the IANA can actually time out an allocation (i.e., do they really have a notion of "temporary"; even though section 3.3 states that the don't need to; who does, and how to the revoke the allocation, etc). The reason I as is that in my role as IANA technical adviser for multicast address assignment, we have the option to make allocations temporary (see RFC 3171), but the IANA can't really execute against that (that is, is seems they have no way of timing anything out; even if that mechanism existed, it doesn't seem that they have the next step, namely, a way to recover the allocation). I suppose this is a long-winded way of saying the "temporary tag" seems (in my experience with the IANA) at best operationally hypothetical. (ii). One weakness with the RFC 2434 subject matter expert approach is that more and more, people just don't care (that is, if you have an application that you can get to enough people that uses some code point that should be IANA assigned, e.g., a port or something), what do you care about what the IANA says (they can't stop you from using it, and if it gets into enough code, well, you get the point; suffice it to say that this happens). In any event, the "pre-RFC deadlock" described below seems to be just the case which will lead to commercial interests overcoming the process(es) you are trying to put in place, and you'll wind up with either the situation described above ("who cares what the IANA says"), or a land-grab for spaces of interest (knowing that the IANA can't really time out the allocations). (iii). Section 2 d) is too vague "There is sufficient interest in early (pre-RFC) implementation and deployment in the community." e.g., how is "sufficient" defined (or for that matter, what is a "community")? So my concern here is that this section is too loosely worded, and as such will open up the IANA to all kinds of early allocation requests. For example, if/when this becomes BCP, will it be possible to claim "sufficient interest" (whatever that is) and use that to circumvent "normal" allocation procedures (noting that the IANA will not be able to evaluate what constitutes "sufficient interest"). (iv). Section 3.2. (Follow-up) This seems to be granting WG chairs the authority to revoke a prior early allocation? "It is the responsibility of the document authors and the Working Group chairs to review changes in the document, and especially in the specifications of the code points for which early allocation was requested to ensure that the changes are backwards compatible." Further, this section seems to create the mechanism for someone to cause some code point to be deprecated (just aruge that a change is required but not backwards compatiable). Just a couple of observations. Dave _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA20502 for ; Thu, 5 Feb 2004 20:42:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov0L-000827-MP; Thu, 05 Feb 2004 20:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aouze-00080p-RE for idr@optimus.ietf.org; Thu, 05 Feb 2004 20:41:18 -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 UAA22558 for ; Thu, 5 Feb 2004 20:41:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aouzc-0001LV-00 for idr@ietf.org; Thu, 05 Feb 2004 20:41:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aouyf-0001Iy-00 for idr@ietf.org; Thu, 05 Feb 2004 20:40:18 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Aouxn-0001F8-00 for idr@ietf.org; Thu, 05 Feb 2004 20:39:23 -0500 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 i161crBm013447 for ; Thu, 5 Feb 2004 17:38:53 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i161crh49553 for ; Thu, 5 Feb 2004 17:38:53 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402060138.i161crh49553@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <98361.1076031395.0@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=none autolearn=no version=2.60 Subject: [Idr] Re: problem with the allocation policy Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 05 Feb 2004 17:38:53 -0800 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98361.1076031395.1@juniper.net> Folks, In thinking about possible (potential) alternatives please look at the attached. Yakov. ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <98361.1076031395.2@juniper.net> Content-Description: forwarded message Return-Path: owner-ietf-announce@ietf.org Delivery-Date: Thu Feb 5 13:14:39 2004 Return-Path: Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by garnet.juniper.net (8.12.8p1/8.12.3) with ESMTP id i15LEdUO004895; Thu, 5 Feb 2004 13:14:39 -0800 (PST) (envelope-from owner-ietf-announce@ietf.org) X-JNPR-Received-From: outside Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.12.9/8.12.3) with ESMTP id i15L9ErT057287; Thu, 5 Feb 2004 13:14:20 -0800 (PST) Received: from asgard.ietf.org ([132.151.6.40]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Feb 2004 13:00:53 -0800 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AoqSA-0000ac-Om for ietf-announce-list@asgard.ietf.org; Thu, 05 Feb 2004 15:50:26 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AoqKY-0000GU-A4 for all-ietf@asgard.ietf.org; Thu, 05 Feb 2004 15:42:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05010 for ; Thu, 5 Feb 2004 15:42:32 -0500 (EST) Message-Id: <200402052042.PAA05010@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kompella-zinin-early-allocation-00.txt Date: Thu, 05 Feb 2004 15:42:32 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-OriginalArrivalTime: 05 Feb 2004 21:00:56.0618 (UTC) FILETIME=[264300A0:01C3EC2B] X-Not-Spam: Spam Score: 2.7 - MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Early IANA Allocation of Standards Track Codepoints Author(s) : K. Kompella Filename : draft-kompella-zinin-early-allocation-00.txt Pages : 7 Date : 2004-2-5 This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the 'Standards Action' IANA policy for protocols where, by the IETF process, implementation and deployment experience is desired or required prior to publication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kompella-zinin-early-allocation-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-kompella-zinin-early-allocation-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-2-5155045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kompella-zinin-early-allocation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kompella-zinin-early-allocation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5155045.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- =_aaaaaaaaaa0-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA12681 for ; Thu, 5 Feb 2004 08:03:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj9p-0000nm-Ut; Thu, 05 Feb 2004 08:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj8u-0000fm-1O for idr@optimus.ietf.org; Thu, 05 Feb 2004 08:02:04 -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 IAA14122 for ; Thu, 5 Feb 2004 08:02:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj8t-00045K-00 for idr@ietf.org; Thu, 05 Feb 2004 08:02:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoj7p-0003zn-00 for idr@ietf.org; Thu, 05 Feb 2004 08:00:58 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoj74-0003pl-00 for idr@ietf.org; Thu, 05 Feb 2004 08:00:10 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 04ACE2D488B for ; Thu, 5 Feb 2004 07:59:40 -0500 (EST) 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 01371-01-10 for ; Thu, 5 Feb 2004 07:59:38 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 493FF2D480C for ; Thu, 5 Feb 2004 07:59:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3EBE7.E94DC064" Message-ID: X-MS-Has-Attach: yes Thread-Topic: BGP-4 implementations - Urgent need input Thread-Index: AcPr5n6S6PfgHYp0TgiiXyjMNWryag== 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] BGP-4 implementations - Urgent need input Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 5 Feb 2004 07:59:38 -0500 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EBE7.E94DC064 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Help! I'm trying to get new work items added to the charter. We are almost there but I need your help to complete this by Friday so I can submit the reports as Internet Drafts.=20 Progress: 1) We got 3 implementation reports=20 (Cisco, Laurel, and NextHop). 2) We got 3 MIB implementations: (Cisco, NextHop, Redback). 3) Reports are written Problem: =20 I need two more things to complete the=20 implementation report:=20 1) a quick note from anyone who implements BGP-4 according to draft-23 the draft telling me: a)who they interoperate with b)if you didn't fill out the survey if the length of the survey (259 questions) was the problem =09 2) A note from anyone with a BGP-4 MIB who implements the following information. If you do, and could fill out the attached MIB report, and send me a=20 snmpwalk of this portion of the MIB that would really=20 help!! (N) bgpPathAttrPeer (N) bgpPathAttrDestNetwork (N) bgpPathAttrOrigin (N) bgpPathAttrASPath (N) bgpPathAttrNextHop (N) bgpPathAttrInterASMetric =20 Please help! Send me a note today if you think you can. Sue =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My thanks to the following people: a big thanks to Alvaro Retano who wrote up the=20 spread sheet and questions for the implementation report. Sharon Chisholm (our resident MIB expert) wrote up the questions for the BGP MIB implementation report. BGP-4 Implementation report folks ----------------------------------------- 1) Alvaro Retano -Cisco (and anyone who helped him) 2) Ardas Cilingiroglu and Manish Vora at Laurel networks, 3) Bill Siadak, Matt Richardson, and Shane Wright at NextHop. BGP-4 MIB implementation report ------------------------------- 1) Enke Chen, Jenny at Redback=20 2) Divya Mukundan , Russ White, and anyone that helped them at Cisco. 3) Jeff Haas at NextHop=20 <>=20 ------_=_NextPart_001_01C3EBE7.E94DC064 Content-Type: text/plain; name="bgp mib checklist1.txt" Content-Description: bgp mib checklist1.txt Content-Disposition: attachment; filename="bgp mib checklist1.txt" Content-Transfer-Encoding: base64 QWdlbnQgSW1wbGVtZW50YXRpb24gQ2hlY2tsaXN0DQoNCiAgICBUaGlzIHNlY3Rpb24gc2hvdWxk IGJlIGNvbXBsZXRlZCBieSBpbmRpdmlkdWFscyBvciBjb21wYW5pZXMgd2hvDQogICAgaGF2ZSBp bXBsZW1lbnRlZCBSRkMgMTY1NyBzdXBwb3J0IGluIGFuIFNOTVAgYWdlbnQuDQoNCiAgICBJcyB5 b3VyIEJHUDQgTUlCIGFnZW50IGFuIGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9uPyAgT3IgaXMg aXQNCiAgICBiYXNlZCBvbiBwdWJsaWMgZG9tYWluIG9yIGNvbW1lcmNpYWwgY29kZT8gIElmIGl0 IGlzIG5vdA0KICAgIGluZGVwZW5kZW50LCB3aGF0IGNvZGUgYmFzZSB3YXMgdXNlZD8NCg0KDQog ICAgSGF2ZSB5b3UgZG9uZSBhbnkgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIHdpdGggbWFuYWdl cnMgdGhhdA0KICAgIGltcGxlbWVudCB0aGUgQkdQNCBNSUI/ICBJZiBzbywgd2hpY2ggbWFuYWdl ciBpbXBsZW1lbnRhdGlvbnMgaGF2ZQ0KICAgIGJlZW4gdXNlZCB3aXRoIHlvdXIgYWdlbnQ/DQoN Cg0KICAgIEZvciBlYWNoIG1hbmFnZXIgd2l0aCB3aGljaCB5b3UgaGF2ZSBpbnRlcm9wZXJhdGVk LCB3aGljaCBvZiB0aGUNCiAgICBmb2xsb3dpbmcgZmVhdHVyZXMgd2VyZSB0ZXN0ZWQ/IER1cGxp Y2F0ZSB0aGlzIHNlY3Rpb24gZm9yIGVhY2gNCiAgICBtYW5hZ2VyLCBhbmQgaW5kaWNhdGUgeWVz IG9yIG5vIChZL04pIGZvciBlYWNoIGZlYXR1cmU6DQoNCiAgICBNYW5hZ2VyIEltcGxlbWVudGF0 aW9uIFVzZWQ6IDxOYW1lPg0KICAgIE9yaWdpbmFsIE1hbmFnZXIgQ29kZSBCYXNlIChpZiBrbm93 bik6ICA8TmFtZT4NCiAgICAoWS9OKSBNYW5hZ2VyIGltcGxlbWVudGVkIGluZGVwZW5kZW50bHkg ZnJvbSB5b3VyIGFnZW50Pw0KICAgIChZL04pIFJlYWQgYWNjZXNzIHRvIEJHUDQgTUlCIHZhcmlh Ymxlcy4NCiAgICAoWS9OKSBXcml0ZSBhY2Nlc3MgdG8gQkdQNCBNSUIgdmFyaWFibGVzLg0KICAg IChZL04pIFNlbmRpbmcgYW5kIHJlY2VpdmluZyBCR1A0IE1JQiBub3RpZmljYXRpb25zLg0KICAg IChZL04pIFRlc3RlZCB1c2luZyBTTk1QdjEvdjJjLg0KICAgIChZL04pIFRlc3RlZCB1c2luZyBT Tk1QdjMuDQoNCg0KICAgIEFyZSB0aGVyZSBhbnkgdW5yZXNvbHZlZCBpbnRlcm9wZXJhYmlsaXR5 IGlzc3VlcyBiZXR3ZWVuIHlvdXIgQkdQNA0KICAgIE1JQiBhZ2VudCBhbmQgYW55IEJHUDQgTUlC IG1hbmFnZXIgdGhhdCBtYXkgaW5kaWNhdGUgcHJvYmxlbXMgaW4NCiAgICB0aGUgc3BlY2lmaWNh dGlvbj8gIElmIHNvLCBwbGVhc2UgcHJvdmlkZSB0ZWNobmljYWwgZGV0YWlscy4NCg0KICAgIChZ L04pICAgICAgICBEb2VzIHlvdXIgYWdlbnQgc3VwcG9ydCBTTk1QdjM/DQoNCiAgICBEb2VzIHlv dXIgQkdQNCBNSUIgYWdlbnQgaW1wbGVtZW50IHRoZSBmb2xsb3dpbmcgDQogICAgb2JqZWN0cz8g IEluZGljYXRlIHllcyBvciBubyAoWSBvciBOKSBmb3IgZWFjaCAgb2JqZWN0Og0KDQogDQogICAg KFkvTikgICAgICAgIGJncFZlcnNpb24gDQogICAgKFkvTikgICAgICAgIGJncExvY2FsQXMgDQog ICAgKFkvTikgICAgICAgIGJncFBlZXJJZGVudGlmaWVyDQogICAgKFkvTikgICAgICAgIGJncFBl ZXJTdGF0ZQ0KICAgIChZL04pICAgICAgICBiZ3BQZWVyQWRtaW5TdGF0dXMNCiAgICAoWS9OKSAg ICAgICAgYmdwUGVlck5lZ290aWF0ZWRWZXJzaW9uDQogICAgKFkvTikgICAgICAgIGJncFBlZXJM b2NhbEFkZHINCiAgICAoWS9OKSAgICAgICAgYmdwUGVlckxvY2FsUG9ydA0KICAgIChZL04pICAg ICAgICBiZ3BQZWVyUmVtb3RlQWRkcg0KICAgIChZL04pICAgICAgICBiZ3BQZWVyUmVtb3RlUG9y dA0KICAgIChZL04pICAgICAgICBiZ3BQZWVyUmVtb3RlQXMNCiAgICAoWS9OKSAgICAgICAgYmdw UGVlckluVXBkYXRlcw0KICAgIChZL04pICAgICAgICBiZ3BQZWVyT3V0VXBkYXRlcw0KICAgIChZ L04pICAgICAgICBiZ3BQZWVySW5Ub3RhbE1lc3NhZ2VzDQogICAgKFkvTikgICAgICAgIGJncFBl ZXJPdXRUb3RhbE1lc3NhZ2VzDQogICAgKFkvTikgICAgICAgIGJncFBlZXJMYXN0RXJyb3INCiAg ICAoWS9OKSAgICAgICAgYmdwUGVlckZzbUVzdGFibGlzaGVkVHJhbnNpdGlvbnMNCiAgICAoWS9O KSAgICAgICAgYmdwUGVlckZzbUVzdGFibGlzaGVkVGltZQ0KICAgIChZL04pICAgICAgICBiZ3BQ ZWVyQ29ubmVjdFJldHJ5SW50ZXJ2YWwNCiAgICAoWS9OKSAgICAgICAgYmdwUGVlckhvbGRUaW1l DQogICAgKFkvTikgICAgICAgIGJncFBlZXJLZWVwQWxpdmUNCiAgICAoWS9OKSAgICAgICAgYmdw UGVlckhvbGRUaW1lQ29uZmlndXJlZA0KICAgIChZL04pICAgICAgICBiZ3BQZWVyS2VlcEFsaXZl Q29uZmlndXJlZA0KICAgIChZL04pICAgICAgICBiZ3BQZWVyTWluQVNPcmlnaW5hdGlvbkludGVy dmFsDQogICAgKFkvTikgICAgICAgIGJncFBlZXJNaW5Sb3V0ZUFkdmVydGlzZW1lbnRJbnRlcnZh bA0KICAgIChZL04pICAgICAgICBiZ3BQZWVySW5VcGRhdGVFbGFwc2VkVGltZQ0KICAgIChZL04p ICAgICAgICBiZ3BJZGVudGlmaWVyIA0KICAgIChZL04pICAgICAgICBiZ3BQYXRoQXR0clBlZXIN CiAgICAoWS9OKSAgICAgICAgYmdwUGF0aEF0dHJEZXN0TmV0d29yaw0KICAgIChZL04pICAgICAg ICBiZ3BQYXRoQXR0ck9yaWdpbg0KICAgIChZL04pICAgICAgICBiZ3BQYXRoQXR0ckFTUGF0aA0K ICAgIChZL04pICAgICAgICBiZ3BQYXRoQXR0ck5leHRIb3ANCiAgICAoWS9OKSAgICAgICAgYmdw UGF0aEF0dHJJbnRlckFTTWV0cmljDQogICAgKFkvTikgICAgICAgIGJncDRQYXRoQXR0clBlZXIN CiAgICAoWS9OKSAgICAgICAgYmdwNFBhdGhBdHRySXBBZGRyUHJlZml4TGVuDQogICAgKFkvTikg ICAgICAgIGJncDRQYXRoQXR0cklwQWRkclByZWZpeA0KICAgIChZL04pICAgICAgICBiZ3A0UGF0 aEF0dHJPcmlnaW4NCiAgICAoWS9OKSAgICAgICAgYmdwNFBhdGhBdHRyQVNQYXRoU2VnbWVudA0K ICAgIChZL04pICAgICAgICBiZ3A0UGF0aEF0dHJOZXh0SG9wDQogICAgKFkvTikgICAgICAgIGJn cDRQYXRoQXR0ck11bHRpRXhpdERpc2MNCiAgICAoWS9OKSAgICAgICAgYmdwNFBhdGhBdHRyTG9j YWxQcmVmDQogICAgKFkvTikgICAgICAgIGJncDRQYXRoQXR0ckF0b21pY0FnZ3JlZ2F0ZQ0KICAg IChZL04pICAgICAgICBiZ3A0UGF0aEF0dHJBZ2dyZWdhdG9yQVMNCiAgICAoWS9OKSAgICAgICAg YmdwNFBhdGhBdHRyQWdncmVnYXRvckFkZHINCiAgICAoWS9OKSAgICAgICAgYmdwNFBhdGhBdHRy Q2FsY0xvY2FsUHJlZg0KICAgIChZL04pICAgICAgICBiZ3A0UGF0aEF0dHJCZXN0DQogICAgKFkv TikgICAgICAgIGJncDRQYXRoQXR0clVua25vd24NCiAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KICAgIERvZXMgeW91ciBpbXBsZW1lbnRhdGlvbiBhbGxvdyBtYW5hZ2VycyB0byB3cml0ZSB0 byB0aGUgZm9sbG93aW5nDQogICAgcmVhZC13cml0ZSBvYmplY3RzPyAgSW5kaWNhdGUgeWVzIG9y IG5vIChZIG9yIE4pIGZvciBlYWNoIG9iamVjdDoNCg0KICAgIChZL04pIGJncFBlZXJBZG1pblN0 YXR1cyANCiAgICAoWS9OKSBiZ3BQZWVyQ29ubmVjdFJldHJ5SW50ZXJ2YWwgDQogICAgKFkvTikg YmdwUGVlckhvbGRUaW1lQ29uZmlndXJlZCANCiAgICAoWS9OKSBiZ3BQZWVyS2VlcEFsaXZlQ29u ZmlndXJlZCANCiAgICAoWS9OKSBiZ3BQZWVyTWluQVNPcmlnaW5hdGlvbkludGVydmFsIA0KICAg IChZL04pIGJncFBlZXJNaW5Sb3V0ZUFkdmVydGlzZW1lbnRJbnRlcnZhbCANCg0KICAgIERvZXMg eW91ciBpbXBsZW1lbnRhdGlvbiBpbmNsdWRlIGVhY2ggb2YgdGhlIGZvbGxvd2luZw0KICAgIG5v dGlmaWNhdGlvbnM/ICBJbmRpY2F0ZSB5ZXMgb3Igbm8gKFkgb3IgTikgZm9yIGVhY2ggbm90aWZp Y2F0aW9uOg0KDQogICAgKFkvTikgYmdwRXN0YWJsaXNoZWQgDQogICAgKFkvTikgYmdwQmFja3dh cmRUcmFuc2l0aW9uIA0KDQoNClBsZWFzZSBlbmNsb3NlIGEgTUlCIHdhbGsgb2YgeW91ciBNSUIg djEgbWliLg0K ------_=_NextPart_001_01C3EBE7.E94DC064-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA20734 for ; Tue, 3 Feb 2004 20:05:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoBTT-0006cQ-4b; Tue, 03 Feb 2004 20:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoBTE-0006bp-2m for idr@optimus.ietf.org; Tue, 03 Feb 2004 20:04:48 -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 UAA15546 for ; Tue, 3 Feb 2004 20:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoBTC-00015R-00 for idr@ietf.org; Tue, 03 Feb 2004 20:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoBSI-00010d-00 for idr@ietf.org; Tue, 03 Feb 2004 20:03:51 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AoBRX-0000q5-00 for idr@ietf.org; Tue, 03 Feb 2004 20:03:03 -0500 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 i1412XBm004308 for ; Tue, 3 Feb 2004 17:02:34 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1412Xh10567 for ; Tue, 3 Feb 2004 17:02:33 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402040102.i1412Xh10567@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75367.1075856553.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=none autolearn=no version=2.60 Subject: [Idr] problem with the allocation policy Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org 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, 03 Feb 2004 17:02:33 -0800 Folks, This is to bring to your attention a problem with the allocation policy that is specified in the current BGP spec. >From the IANA Considerations section of the current BGP spec: All new BGP message types, Path Attributes Type codes, Message Header Error subcodes, OPEN Message Error subcodes, and UPDATE Message Error subcodes MUST only be made using the Standards Action process defined in [RFC2434]. >From rfc2434: Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. The problem with the Standards Action policy is that it makes impossible to assign a value when a document is just an Internet Draft. Yet in the routing area to advance an Internet Draft to even a Proposed Standard requires more than one (interoperable) implementation as a prerequisite for the advancement. Which means that it is necessary to assign a value when the document is still an Internet Draft, prior to the approval by the IESG. So, the bottom line is that the Standards Action policy, as *currently* specified in rfc2434, is unsuitable (and not just for IDR, but for any WG in the Routing Area). Yakov. P.S. In fact, any policy that requires an RFC for the assigment is likely to be unsuitable (not just for IDR, but for any WG in the Routing Area). _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr